Hi, Is this more achievable if you start with Alex's step "3) Change the event model" instead of starting by removing widget->window?
I wonder if stuff would break much if you made one basic change: add capturing. i.e. send events down from the window-owning widget through all children that are at the event coordinates. Then, no window widgets don't need an input-only window to get events. The breakage still includes - no-window widgets would now get events when they did not before (but old no-window widgets should ignore them, right?) - no-window widgets relying on now getting events would break with unported containers that don't know to forward events (but all the containers in GTK would be ported, and GtkContainer could have a default implementation that would almost always work I bet) I can think of some ways to implement it, not sure which is best. 1. "HippoCanvas recursive style" is that GtkWidget::event, for containers, would locate the child whose allocation the event was inside, translate the event coordinates to be relative to that child, and invoke GtkWidget::event on the child. GtkContainer could have a default implementation of this that would work almost always. If a container handles an event itself of course it doesn't forward to the child. * have to figure out how to then bubble up (gtk_propagate_event). maybe an "up/down" "capture/bubble" flag in the event itself? (the issue if not obvious is that the event method does something different for going up vs. going down) (question: replace gtk_propagate_event with code that goes in the event handler?) * if x,y are translated to widget coordinates (principle: widgets always see coords relative to themselves) then event->window is weird/confusing. possible solution: add window_x, window_y to events for people who really need window-relative, then define x,y as widget-relative. only breaks back compat for parents looking at events from descendant windows, but could even fix that by un-translating events during bubble up. (so ancestors of the original window-owning widget would see window-relative not self-relative coords.) maybe better to just break compat, not sure. Or for full back compat, add widget_x widget_y and leave x,y window-relative, but makes code ugly. * IMO recursion is more cleanly encapsulated (and more "overridable") than the global functions do_event, propagate_event, get_event_widget in gtkmain.c. Those would be replaced with default implementation in GtkContainer and/or utility functions to be used when writing widgets. * It might be useful to start capturing events at the widget owning the GdkWindow, not the toplevel. This improves back compat since window widgets will still get first crack at events and could even choose not to capture down to their children. Window widgets become "capture toplevels." 2. add a new GtkWidget::capture signal that would send events down, possibly recording the leaf widget reached; at the end of capture, gtk_propagate_event on the leaf widget that was reached. really just a variant of 1, except ::event remains bubble-up-only, while the new capturing is its own signal. 3. add a new method to GtkContainer that virtualizes gtk_get_event_widget(), GtkContainer::get_event_widget(), then call normal gtk_propagate_event(). downside: no capture, i.e parents can't take events from children. However, still allows no-window widgets to get events. 4. add global code to gtkmain.c that walks the widget tree and forwards events using widget allocations, so no-window widgets can get events * might still need to solve the "translating event coords to widget coords" problem, if only with a gtk_widget_translate_coords(widget, event, &x, &y) kind of utility function * avoids modifying containers but also keeps containers from doing anything custom Anyhow, given something along these lines, you drop the input-only windows at your leisure and over time, and no window widgets could still get events. You would also at some point (potentially post 3.0) implement the non-window-using clipping and scrolling and you could one by one port widgets to use that. This seems more possible to do post-3.0 than changing the event model, perhaps? For example a clip-to-allocation property much like Clutter's would be a natural future compatible change. In 3.0 you'd need to hide internal GdkWindow like those in TextView, maybe by adding some kind of new "border window event" signal to text view to replace looking at event->window. Once widgets aren't using GdkWindows for events, clipping, or scrolling, now you can go to Alex's steps 1 and 2, though in 3.x it would just be "deprecate CSW logic and widget->window" rather than removing them, I suppose. You wouldn't get the code deletion and GDK internals simplification for 3.x, so no joy for GTK maintainers. Still, you would get all the advantages for apps and widget writers... Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list