On Thu, May 17, 2012 at 4:36 PM, Jasper St. Pierre <jstpie...@mecheye.net> wrote: > 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
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). _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
