Re: rendering-cleanup worries

[Havoc Pennington <hp pobox com>]

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