[compiz] Thumbnail plugin
davidr at novell.com
Fri Jan 26 15:52:12 PST 2007
On Thu, 2007-01-25 at 14:59 +0100, Dennis Kasprzyk wrote:
> > On Wed, 2007-01-24 at 17:25 +0100, Stjepan Glavina wrote:
> > > When hovering taskbar, gnome-panel/kicker change the property of the
> > > appropriate window ("_NET_WM_SHOW_THUMBNAIL").
> > > Thumbnail plugin checks for PropertyNotify events and shows/hides the
> > > thumbnail.
> > (I assume that you didn't want take this discussion off the list)
> > This discussion should eventually be moved to the wm-spec-list but
> > there's a few things I think we should try to decide here first.
> > 1. Should one window only be allowed to show one thumbnail or should the
> > property be a list of thumbnails?
> > 2. How is the position and scale of the thumbnail encoded. Is it:
> > data = thumbnail window ID
> > data = x
> > data = y
> > data = width
> > data = height
> > x, y being relative to the client window position.
> > 3. The compositing manager might have to do some work before it can
> > render the requested thumbnail(s) in a client window. The client
> > wouldn't want the window which contains thumbnails to be visible until
> > all thumbnails can be rendered properly. If the client sets the
> > thumbnail property prior to mapping the window, it allows the
> > compositing manager to delay any drawing of the client window until the
> > requested thumbnails can be rendered. Some of this might need to be
> > documented before it can be accepted as an addition to the EWMH spec.
> > 4. What windows are valid in the thumbnail property? Any window in the
> > _NET_CLIENT_LIST root window property? Or should there be a new
> > _NET_THUMBNAIL_LIST property? Such a list means that the compositing
> > manager doesn't have to provide thumbnails for all available windows,
> > which makes sense for the current state where thumbnails for minimized
> > windows can't be rendered.
> > If someone can think of something else, please jump in.
> > - David
> I also don't think that rendering the complete thumbnail window (what the
> current state of the thumbnail plugin is) should be the final solution. This
> should be done by the requesting application and the composite manager should
> render only the window thumbnail into it. So here is my idea:
> 1. We should think about a _NET_CM naming schema, because these are composite
> manager abilities and there may still be separated window and composite
yes, that discussion should probably be moved to wm-spec-list at gnome.org
> 2. A window should have a _NET_CM_SUPPORTS (or _NET_CM_PROTOCOLS) list that
> contains all features supported by the composite manager for that window. I
> this case it would be _NET_CM_THUMBNAIL. This could be easily removed if a
> window gets minimized. This list could then be also used to inform a client
> about other features like opacity,brightness,saturation...
> 3. If a application wants that a thumbnail (or more) should be rendered into
> it's window, it simply sets the _NET_CM_THUMBNAIL atom with a list of the
> data = thumbnail window ID
> data = x
> data = y
> data = width
> data = height
> data = next thumbnail window ID
> x/y relative to the application window.
pretty much what I had in mind.
> Because the composite manager already renders the application window it should
> not be timing issue to render the thumbnails into it.
If the window hasn't been visible for a while (like a minimized window)
the compositing manager is likely going to keep the window unmapped to
save resources. Mapping and the initial repaint of the thumbnail window
will in those cases take some time.
> If someone would like
> to create a "switcher like" application outside of the composite manager,
> setting of the thumbnail atom before mapping might be a disadvantage.
In what way can it be a disadvantage? I'm not suggesting that it must be
set before the window is mapped, just that it could and we might want
the spec to say that the compositing manager is allowed to delay
rendering of the window until thumbnails are available. Not sure that
it's necessary to mention this in the spec though.
> should also think of a system, how to allow that the opacity, brightness, and
> saturation (or any other supported feature) could be set only for the
I think we want to leave that out initially. I can't think of a lot
situations where that would be useful.
More information about the compiz