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 _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
