Re: Signals for when any window changes in any way

["Jasper St. Pierre" <jstpierre mecheye net>]

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