Re: Tiling features in Mutter
- From: Tim Cuthbertson <tim gfxmonk net>
- To: Oliver Mangold <o mangold googlemail com>
- Cc: gnome-shell-list gnome org
- Subject: Re: Tiling features in Mutter
- Date: Fri, 18 Mar 2011 08:04:32 +1100
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?
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
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]