Re: Signals for when any window changes in any way

[Amy C <mathematical coffee gmail com>]

On Thu, May 17, 2012 at 4:36 PM, Jasper St. Pierre
<jstpierre mecheye net> wrote:
> On Thu, May 17, 2012 at 2:21 AM, Tim Cuthbertson <tim gfxmonk net> wrote:
>> On Thu, May 17, 2012 at 2:00 PM, Amy C <mathematical coffee gmail com> wrote:
>>> Hi all,
>>>
>>> I'm currently having fun porting xpenguins to a gnome shell extension
>>> (yes pointless I know, but fun), and I basically need to keep track of
>>> where every window is on the screen at all times. This is so that
>>> toons can walk on the windows as if they were physical objects.
>>>
>>> I'm trying to decide between two ways of doing this:
>>>
>>> 1) for each frame of the animation, loop through all the windows &
>>> build up the region, just as a union of rectangles.
>>>
>>> 2) listen to the following events and update the region whenever it gets fired:
>>> - window tracker: "minimize", "maximize", "unmaximize", "switch-workspace"
>>> - for each workspace: "window-added", "window-removed"
>>> - whenever the workspace that XPenguins is running in is destroyed:
>>> "notify::n-workspaces"
>>>
>>> - whenever a window moves or changes size (including while they are
>>> resizing/dragging): ??what event signal??
>>> - whenever window stacking order changes ??what event signal??
>>>
>>> In case it's relevant, "rebuilding the window region" means looping
>>> through all windows on the specified workspace and adding their
>>> `get_outer_rect()` to a list.
>>>
>>> Now 1) is simple, but perhaps is inefficient - I'm using a
>>> Clutter.Timeline (for now) to do the animation, and (I think) it does
>>> one new frame per monitor refresh rate (roughly). So rebuilding the
>>> window region could get slow, especially since users aren't usually
>>> moving their windows around all the time.
>>>
>>> Number 2) seems a little better in that the window region is only
>>> updated when it needs to be, which is almost certainly going to be
>>> less than once per frame.
>>> However since there are so many events to connect up, I'm a bit
>>> worried about missing some. Have I covered all of them above? All I
>>> need is a list of window rectangles that is *always* up-to-date, so
>>> I'm after any events pertaining to this.
>>> Also, what is the relevant signal for windows changing
>>> size/position/stacking order? (If you resize or move a window over a
>>> toon it'll get squashed.)
>>
>> I attempt to do pretty much the same thing in shellshape. It's not
>> easy, but I think it's fairly exhaustive (i.e I don't notice it being
>> out of sync with a window's actual position):
>> https://github.com/gfxmonk/shellshape/blob/master/shellshape/workspace.js#L162
>>
>> points of note:
>>
>>  - the actor (the thing that resize and move signals come from) is not
>> present when the window first appears, so you have to keep checking
>> (by adding your function to the idle loop) until it's non-null. Also,
>> it's accessed by "get_compositor_private()" which is both scary and
>> unobvious.
>>
>>  - resize / move signals happen continuously when a window is being
>> dragged. I only care about when the drag is over, so I have to to
>> extra work there to only trigger a relayout when I detect that a drag
>> has finished. You'll probably want to do something similar - even if
>> you want to update periodically, doing work every time a resize event
>> is triggered is probably too frequent.
>
> This is what the grab-op-begin/grab-op-end signals are for.
>
>> _______________________________________________
>> gnome-shell-list mailing list
>> gnome-shell-list gnome org
>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
>
> --
>   Jasper

Cheers - I'll go with the second method of updating the window region
whenever an appropriate signal is raised for efficiency's sake.
Tim - thanks tremendously for that, it'll be nice to be able to
cross-check a list of window signals with someone else's list.
Jasper - thanks too! this will save a bit of footwork.
When I eventually get all these events handled, I start work on
stacking order (I'm making a modification to XPenguins whereby you can
run it in a window of your choice, and only windows that obscure the
XPenguins window should squash penguins).

Will let you all know how it goes when the extension's runnable
(probably a while away).