Hi, I've collected a whole bunch of changes in th wip/baedert/drawing branch. Here's a little overview of how things work in there, so we can decide if it's the right way forward.
Internals: - gtk_widget_snapshot automatically draws CSS background and border for all widgets. It then calls the ->snapshot vfunc so the widget can draw contents, then it draws a focus rectangle if gtk_widget_get_has_visible_focus returns TRUE. - gtk_widget_real_snapshot calls gtk_widget_snapshot_child on all the child widgets of the given GtkWidget instance. This makes sense to me but it's already been problematic when porting GtkScale and GtkRange away from gadgets because GtkRange didn't override ::snapshot so GtkScale couldn't just subclass it and chain up, since it would cause all child widgets to be drawn twice. - gtk_widget_measure cares about CSS min-width/min-height, as well as CSS margins, padding and borders. So gtk_widget_size_allocate_with_baseline first sets the widget's allocation to the given one and then passes the content allocation, i.e. the one without CSS margin, border and padding down to the size-allocate vfunc. I.e. in the size-allocate implementation, widgets receive their new content allocation, not the entire widget allocation. If they still need the widget allocation, they can call gtk_widget_get_allocation of course since the allocation has been set before calling ::size-allocate. There are currently gtk_widget_get_margin_allocaiton, _border_allocation and _content_allocation implementations private. - For clips, all widgets *have to* currently call gtk_widget_set_clip at the end of their size-allocate implementation. gtk_widget_set_clip will union the given clip with the box-shadow size and the widget allocation minus CSS margins. - Since we always automatically set the allocation of a widget before calling its ::size-allocate vfunc, gtk_widget_set_allocation is gone. Widgets: - GtkSpinButton is now a direct GtkWidget subclass that contains a GtkBox that contains a GtkEntry and two GtkButtons. That was easier than expected since GtkSpinButton already (partially) implemented GtkEditable. It also means that currently the blue focus outline around the entire spin button is broken. Dunno if there's some CSS magic that would fix this or if that approach for the spinbutton is just wrong. - GtkRange is not abstract anymore. Not because I really want to but because it was needed for GtkScrollbar. Not sure if that's right or if we can use it as a general "slider inside trough" widget. - GtkScrollbar is now a direct GtkWidget subclass containing a box that contains a GtkRange. That works out mostly fine in practice but of course people can't call GtkRange API on it anymore, so gtk_scrollbar_get_adjustment has to be used, etc. The stepper buttons are currently gone but since it contains a GtkBox they should be relatively easy to add back, I've just not heard a good solution to how we should hide/show them without the style properties. - GtkCheckButton is now a GtkBin subclass containing a GtkTogglebutton that contains a GtkIcon as indicator and the actual bin child. This consequently means that GtkToggleButton API can't be used on a GtkCheckButton anymore, which is pretty painfull for porters, and there's not really an automatic way of fixing this since the old gtk_tool_button_{get,set}_active for example are still valid calls. - GtkNotebook lost all its gadgets. There's stil some bug triaging to be done though. I'm not sure if it doesn't suffer from being unable to show/hide widgets in ::size-allocate now. - The last remaining gadgets are the progress and icons in GtkEntry as well as the handle gadget in GtkPaned, but I'd like to wait for the event-delivery branch to get merged to master first. - Since GtkPopover looks at the margins manually and considers them in its ::measure implementation, popovers are currently slightly higher (or wider, depending on the arrow position) than they should be. Remaining problems/open questions: - Both GtkWindow and GtkPopover are special-cased in gtk_widget_snapshot to not draw the CSS background and border for them, since they are just too special. Getting rid of that special case would require porting them away from manual background drawing. - There are lots of CSS problems now of course, e.g. GtkRevealer does not hide its padding anymore so GtkSearchBar always leaves a few pixels of space around, or the 4px margin around GtkMenu which is not applied inside the toplevel instead of outside. Also GtkCheckButton obviously. - Focus outlines work out pretty badly the way they are currently done in the branch. Wit gadgets, widgets had pretty fine-grained control over which gadget draws the focus outline. - I've had to make lots of changes to make clips work the way they do now, but it seems like the clip should always default to the allocation (like it always did), but then it doesn't consider the box shadow. - Baselines are pretty screwed up, but they are already broken in master and as long as coordinates are in flux, I don't want to look in to that just to have them broken again. - GtkScale has a ::format-value signal. In the past, this has been emitted on every draw (or size-allocate?), when the PangoLayout was created. The widget-factory uses that (and returns a g_strdup (" ")) to hide the value entirely. This does not work anymore on startup, because the value is not being displayed in a GtkLabel and we only change the label when the adjustment's value changed. So, if you first set the adjustment and then connect to ::draw-value, we'd need to automatically invoke it once to set up the initial value string. - Generally lots of smaller things. I have a list locally, but lots of those depend on wip/carlosg/event-delivery getting merged first so I don't have to fix them twice. Cheers, Timm _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list