Re: Implementation of new EWMH spec



On Tue, 2006-04-18 at 01:49 +0200, Soeren Sandmann wrote:
> > - I wonder if it is necessary to propagate the signal throughout the
> > widget hierarchy.
> >   Isn't it enough to have the signal on GdkScreen ?
> 
> It is quite painful to keep track of whether a screen is
> composited since you have to also keep track of when the screen
> changes. Having the signal on the widget means not only that this
> becomes much easier, but also that gtk+ can guarantee that a widget is
> invalidated when the composited-status changes. That way, a simple
> widget can just check gdk_screen_is_composited() in the expose
> handler. 

If I were writing an app, I'd prefer to have a centralized place to get
all the rgba/composited stuff, and that place should be GdkScreen.  That
way, I'll look at what API it provides and:

1. See that I can get an RGBA visual from it

2. I can remember to pay my taxes and connect to
GdkScreen::composited_changed.

3. Remember that yes, I may be running on a multiscreen setup as well,
and also pay my taxes by connecting to the appropriate signals.

Spreading the "is_composited/composited_changed" API among GdkScreen and
GtkWidget means that people will just ignore the latter's signals, since
they won't ever see them.

Right now people have to do a *lot* of stuff to write a proper widget:
handle changes in the screen, icon theme, style, compositing manager,
text direction, ::show_help (which nobody handles), ::grab_broken_event
(which is too new, so nobody handles it either)...  I'd rather reduce
the number of things that people have to keep in mind :)

  Federico




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]