Re: Implementation of new EWMH spec
- From: Federico Mena Quintero <federico ximian com>
- To: Soeren Sandmann <sandmann daimi au dk>
- Cc: gtk-devel-list gnome org
- Subject: Re: Implementation of new EWMH spec
- Date: Tue, 18 Apr 2006 11:00:06 -0500
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]