Re: rendering-cleanup worries
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-
Re: rendering-cleanup worries
After reading this mail I think we pretty much 100% agree on the ideal world. The hard part is just figuring out how to get there. I see 2 problems with this: 1) developer time to actually implement this for GTK3. 2) keeping the code changes for app developers small. So if we don't manage to get this for 3.0, can we get it for 3.x? If so, do we need to prepare 3.0 in ways that make it possible? And if we don't get it done for 3.0, can we prepare 3.0 so that we can get this done as easily as possible for 4.0? On Mon, Aug 23, 2010 at 10:39 PM, Alexander Larsson wrote: > I don't particularly care if we "break" mozilla or eclipse as they exist > now. I mean, we already do that just by breaking the abi. Its more that > I fear that the needs of something more complex like a full desktop with > panels, systrays, desktops, browser plugins, document object embedding, > etc. at times do require "weird" stuff in the lower layers to make it > work. And there is a risk that not allowing "weird" stuff will cause > problems down the line. > I try very hard to talk to people about all these things. And that includes all the parts that make up a desktop. But the "weird" things in a desktop usually rely on X11 and not GDK (a very sincere thanks for that to the KDE guys ;)) and can be solved that way. I think it was misguided to let GDK be a complete wrapper around X11 instead of a useful sugary layer on top. So I suggest we encourage poking at libX11 directly if you do stuff that relies on X11 constructs. And then we do a useful abstraction on top that provides the common requirements as easily as possible. The nice side effect of that approach is that it's way easier to port to other systems. > 2) Remove GtkWidget->window. > > [...] > That's basically what I'm aiming for with my cleanup work and gtk_widget_draw(). Though as we've talked about it, I'm working on my fallback plan to honor windows and work with them while they are there. The nice side effect is that it's something that could be done step-by-step during GTK 3.x: Slowly make all widgets not have windows anymore. > 3) Change the event model > > GdkWindow still deliver "native style" events to the toplevel, > but this is converted by GtkWindow or suchlike to a DOM style > capture (go down) then bubble (go up) model. This event handling > would be done by the widgets, and as such wouldn't look exactly > like the current one (no masks, widgets can control how events > look like to the lower hierarchy, etc). > We do almost have that functionality inside GTK though, don't we? I mean, the csw work you did is basically doing this whole event dispatching work on the client side. Or am I missing the boat? I have never really looked at event dispatching, so I might be way off here. > However, it would also make porting existing widgets a major endeavor. > You need to basically redo the whole event and repainting system for the > more complex widgets like the treeview and textview. It definitely will > not be the almost-trivial kind of porting changes you've talked about > before, with the expose to draw() conversion. Although for a typical app > that just uses widgets it might not be that much of a change. > Would it be that complicated? It might involve some work for the more complex container widgets (the ones with more than 1 child) and the ones that haven't been touched in ages and do magic with GdkWindows, like the ones you mentioned. But that's not what most widgets do. And maybe we could even keep widget->window and make it possible to transition slowly during GTK 3.x? Again, I have no idea about the amount of work involved here, but speaking purely from a rendering POV, it shouldn't involve much work. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup worries
On Mon, 2010-08-23 at 10:07 +, Benjamin Otte wrote: > Alexander Larsson redhat.com> writes: > > It may seem correct and easier, and in most cases it will work. But > > things like that were added for a reason. In this case it is to make > > things like notification icon work, where there the parent of the window > > we paint in is a foreign window (the tray) so we don't know what > > background it has set. Using a native X clear function means we'll get > > this right anyway. Without this change all systray icons get a black > > background. > > > Looks like I'll have to fix gtkstatusicon.c to call XClearArea. Yeah, for a non-container widget like statusicon something like that its probably enough. I don't mean that this particular problem is impossible to solve, just using it as an example of the little details that will haunt you as you try to use any new larger redesign. > > In general I'm a bit worried about the rendering cleanup branch wrt > > non-obvious issues like this. After doing the "simple" part of the csw > > work I spent many months chasing minute issues like this to make the > > full desktop with all its apps work with csw. > > > I don't think it's GTK's job to have corner-case workarounds for weird > platform issues. If that were the case, we could just get rid of GDK and > use libX11 directly. To me GDK is supposed to be a useful abstraction to > write a portable widget toolkit, so I'm not too worried about not handling > corner cases as long as we allow apps to handle them on the libX11 level > should they care. I don't think its gdks job to handle the corner cases, however it is the interface to the lower layers that *lets* you solve the. It is the interface between the libX11 level and the gtk level, and as such it is inherently shaped by how the underlying implementation works. > > I fear that we will not be > > able to do this with gtk3, because there are not enough apps to expose > > all the corner case issues we might hit before we release, and by then > > we're frozen and may be unable to fix some issue. > > > This won't happen unless we get some more developers spending time on this > stuff. And so far I'd say there's just me - and a large group of > enthusiastic but worried bystanders. > > Still, GTK3 is an API and ABI break, so we can allow semantic changes. If > we intend to keep GTK3 rendering 1:1 compatible with GTK2, then I should > probably stop doing this work, because it definitely is intrusive enough > to break things, in particular for apps that rely on weird corner cases > (like Mozilla or Eclipse). This is not intended to be like your csw work > where you were trying to guarantee binary compatibility. In fact, one of > my goals is the direct opposite: I want to make the code easier. And I'm > happy to sacrifice lots of corner cases for this. I don't particularly care if we "break" mozilla or eclipse as they exist now. I mean, we already do that just by breaking the abi. Its more that I fear that the needs of something more complex like a full desktop with panels, systrays, desktops, browser plugins, document object embedding, etc. at times do require "weird" stuff in the lower layers to make it work. And there is a risk that not allowing "weird" stuff will cause problems down the line. Anyway... I don't want to seem like a backwards person. I very much agree that by breaking a few eggs Gtk3 could be a much better omelet. I think I understand where you're going with your reasoning, but I think you're slightly off. If I were to do a larger change of the underlying gtk+ system like you're proposing I would do it a bit differently: 1) Kill all the csw rendering and event propagation from GdkWindow. Make a GdkWindow simple and one-to-one with a native window. In your typical app there will only be one such for each window, but in "weird" situations (like Xembed and such) it would let you create subwindow that have a reference in the gtk+ world so that the internals know about their existance and status and can do the right things. Also, we could probably simplify the window operations a bit as many things might not be needed anymore. This way Gdk is again just a porting layer for the non-drawing part of the windowing system. 2) Remove GtkWidget->window. All windows just render in the cairo_t they get to draw in, and such rendering is clipped by the painting algorithm traversing the widget hierarchy, unrelated to any windows. Scrolling and suchlike is implemented by widget clipping and offsets/transforms (although we would need to make sure there are special casing for axis-aligned rect scrolling so we don't always repaint everything when scrolling). 3) Change the event model GdkWindow still deliver "native style" events to the toplevel, but this is converted by GtkWindow or suchlike to a DOM style
Re: rendering-cleanup worries
On 23/08/10 11:07, Benjamin Otte wrote: Alexander Larsson redhat.com> writes: I fear that we will not be able to do this with gtk3, because there are not enough apps to expose all the corner case issues we might hit before we release, and by then we're frozen and may be unable to fix some issue. This won't happen unless we get some more developers spending time on this stuff. And so far I'd say there's just me - and a large group of enthusiastic but worried bystanders. We (as a company) may be spending some time in this area soon (people are on vacation at the moment) and we have already been playing with it (at GUADEC) in projects like Sapwood and GIMP to make sure everything works on top of the new changes. Keep up the great work here Benjamin! -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup worries
Alexander Larsson redhat.com> writes: > It may seem correct and easier, and in most cases it will work. But > things like that were added for a reason. In this case it is to make > things like notification icon work, where there the parent of the window > we paint in is a foreign window (the tray) so we don't know what > background it has set. Using a native X clear function means we'll get > this right anyway. Without this change all systray icons get a black > background. > Looks like I'll have to fix gtkstatusicon.c to call XClearArea. > In general I'm a bit worried about the rendering cleanup branch wrt > non-obvious issues like this. After doing the "simple" part of the csw > work I spent many months chasing minute issues like this to make the > full desktop with all its apps work with csw. > I don't think it's GTK's job to have corner-case workarounds for weird platform issues. If that were the case, we could just get rid of GDK and use libX11 directly. To me GDK is supposed to be a useful abstraction to write a portable widget toolkit, so I'm not too worried about not handling corner cases as long as we allow apps to handle them on the libX11 level should they care. > I fear that we will not be > able to do this with gtk3, because there are not enough apps to expose > all the corner case issues we might hit before we release, and by then > we're frozen and may be unable to fix some issue. > This won't happen unless we get some more developers spending time on this stuff. And so far I'd say there's just me - and a large group of enthusiastic but worried bystanders. Still, GTK3 is an API and ABI break, so we can allow semantic changes. If we intend to keep GTK3 rendering 1:1 compatible with GTK2, then I should probably stop doing this work, because it definitely is intrusive enough to break things, in particular for apps that rely on weird corner cases (like Mozilla or Eclipse). This is not intended to be like your csw work where you were trying to guarantee binary compatibility. In fact, one of my goals is the direct opposite: I want to make the code easier. And I'm happy to sacrifice lots of corner cases for this. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
rendering-cleanup worries
I don't have very much time to work on the rendering-cleanup stuff, but I do look at it now and then. This change caught my eye today: http://git.gnome.org/browse/gtk +/commit/?h=rendering-cleanup&id=eb6e2bddc86746bd90f617489d1c423c17c1959b It may seem correct and easier, and in most cases it will work. But things like that were added for a reason. In this case it is to make things like notification icon work, where there the parent of the window we paint in is a foreign window (the tray) so we don't know what background it has set. Using a native X clear function means we'll get this right anyway. Without this change all systray icons get a black background. In general I'm a bit worried about the rendering cleanup branch wrt non-obvious issues like this. After doing the "simple" part of the csw work I spent many months chasing minute issues like this to make the full desktop with all its apps work with csw. I fear that we will not be able to do this with gtk3, because there are not enough apps to expose all the corner case issues we might hit before we release, and by then we're frozen and may be unable to fix some issue. Note, I'm not fundamentally against the cleanups, in fact I like them. I'm just worried that they will cause unforseen problems down the line unless we can really get it fully battle tested (i.e. not only demos and tests) before being frozen. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a deeply religious guitar-strumming werewolf for the 21st century. She's a strong-willed renegade advertising executive looking for love in all the wrong places. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
