On Thu, May 17, 2012 at 2:21 AM, Tim Cuthbertson <t...@gfxmonk.net> wrote: > On Thu, May 17, 2012 at 2:00 PM, Amy C <mathematical.cof...@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 _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
