Owen Taylor <otaylor <at> redhat.com> writes: > My basic idea is to have a "Window Clock" object that serves as the > central point of timing coordination for each toplevel window. > Why is this a property of a window? Aren't clocks specific to a screen/display? >From the message you sent to wm-spec list it looks like a per-window approach. Is that just for convenience or do you expect window managers to paint different windows at different times?
Also, I'm not sure that exposing a separate object is a good idea. Handling redraws is a feature of a window to me, not something you want to split out. Unless we expect applications to care about which clock is used with which window, which brings me to the next point: Do you expect the clock to be mutable? Because I can't come up with any usecase for it, let alone a sane way to implement this. > /* Get the singleton window clock for a toplevel window */ > GdkWindowClock *gdk_window_get_clock (GdkWindow *window); > > The window clock object has two signals: > > ::layout > ::draw > Isn't the only information the window can provide that a previous paint cycle has completed and a new paint cycle can now start? So the differentiation between a "layout" and a "draw" step is an implementation detail that you would introduce inside GDK that is not a feature of the underlying windowing system, right? Because if so, we could hide that step and not expose it in the public API. We could then do a relayout + paint cycle from expose events internally (inside GTK probably). And then it almost seems like the only thing a GdkWindow would need to care about is when to send the next expose event. Another thing I'm not sure is how toplevel resizes would work with this. Because in current GTK a relayout means a resize which potentially needs a different size from the toplevel. And that needs communication with the WM somehow. Did you spend time thinking about that problem? > It also has can have any number of "clock targets" objects added to it: > > void gdk_window_clock_add (GdkWindowClock *clock, > GdkClockTarget *target); > void gdk_window_clock_remove (GdkWindowClock *clock, > GdkClockTarget *target); > > GdkClockTarget is a simple interface: > > struct _GdkClockTargetClass { > GTypeInterface base_iface; > > void (*update) (GdkClockTarget target, > GdkWindowClock *clock); > }; > > When there is at least one clock target added, the clock is "on", and > whenever it's time to draw a frame, each clock is updated. > I commented about this on IRC, and it seems to me that this looks like a signal more than something that needs an interface. Of course, we'd need to have a way to be notified about signal addition/removal by gobject, but that is a much-requested feature these days. Or is there something else that makes this something we should go through to implement a "real" Observer pattern. One thing that your mail does not touch at all and that I consider quite crucial is how to handle timing problems. We have a lot of widgets that take their time and easily take 100ms to relayout or draw. And I'm sure other applications have those, too. So any solution that we come up with will need to account for that. Not sure how related that is to your mail though. And there's all the problems with the current GTK design that Havoc pointed out in the mail he linked to. I think we'd first need to solve those with the current API before we can attempt to invent something new. And I'd rather get this interface right than try to hack it into the current mess we have in GTK. Benjamin _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list