Re: Tiling features in Mutter

[Tim Cuthbertson <tim gfxmonk net>]

On Fri, Mar 18, 2011 at 8:04 AM, Tim Cuthbertson <tim gfxmonk net> wrote:
> I'm not seeing owen's side of this conversation (specifically this
> first quoted part, I never received. this is also the first message
> I've seen discussing static typing vs dynamic typing). is it supposed
> to be between the two of you or on the mailing list?

Disregard that. I just found the other half of the conversation in
that other tiling thread ;)

> On Fri, Mar 18, 2011 at 4:07 AM, Oliver Mangold
> <o mangold googlemail com> wrote:
>> On 17.03.2011 16:23, Jeffery Olson wrote:
>>>
>>> Encapsulation, low coupling and seperation-of-concerns. These are all
>>> valuable patterns that we can leverage here.
>>
>> Okay, you have a point here. This is certainly the best one can do under
>> dynamic typing.
>>
>> I'm not sure if it is relevant for the specific project, but still I can
>> think of situations where it is not possible to run the API-using code
>> directly, e.g. if a hook to a signal that will only be raised on user
>> action, the interface of the hook call cannot be tested.
>>
>>> Now, this doesn't negate the need to test a set of bindings to the
>>> mutter/gnome-shell C codebase for API churn. What we need is a way to
>>> get access to a Looking Glass-like REPL from the CLI, that would maybe
>>> fire up a new process with a "sandboxed" gnome-shell session that
>>> wasn't actually bound to an xdisplay, but that we could use to verify
>>> bindings, etc. This, once again, falls into the "not yet done"
>>> category. I don't know the feasibility of such an endevour. There's a
>>> possibility to eval javascript code in the current gnome-shell session
>>> via dbus, but I haven't explored this much either (and don't know how
>>> useful itd really be).
>>
>> Of course much can be done in principle, but it still will be a lot of work
>> for the writer of unit tests. Even if you have this, you still have to bring
>> this sandbox environment into a state, where it is possible to call the
>> function you want to test, e.g. if you call workspace.get_windows() you
>> probably should have some windows open, and if your function only messes
>> with windows that fulfill a certain condition (tiled, maximized, specific
>> title, ...) you first have to bring a window in the specific state, etc.
>>
>> I must admit, though, that static typing is not a cure to detect all API
>> incompatibilities, e.g. if the behaviour of a method changes but not the
>> interface, still it is something I like very much, as for real world
>> purposes it finds quite a lot problems simply by compiling.
>>
>> _______________________________________________
>> gnome-shell-list mailing list
>> gnome-shell-list gnome org
>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>>
>