Re: Signals for when any window changes in any way

[Tim Cuthbertson <tim gfxmonk net>]

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.