We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
gtk_snapshot_pop() => removed
gtk_snapshot_pop_and_append() => gtk_snapshot_pop()
So now there is no way to get a rendernode out of the snapshotting API
until you gtk_snapshot_finish().
Instead of making people intiialize a rectangle and then applying border
radius manually, provide a constructor that does it for them.
While doing that, also allow people to instead request the padding box
or the content box.
Refactor all relevant code to use this new constructor.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
Instead of taking the border and manually removing it from the
allocation, render our background over all the border allocation box, as
that's more correct and does not take padding into account twice.
I misunderstood what the overlay is good for: We need to allocate
it the full size of the widget. since we are using it to render
a background gradient *over* the application-rendered color.
At the same time, save some 100 lines of code by using an icon
helper as gadget, instead of handling the icon manually.
gtk_render_content_path is expecting the full box dimensions,
not just the content area. So, add the border before calling it.
Note it is still possible to have some separation between the
color and the border, by setting padding.
Use a .activatable style class on the color swatch and tie the
hover effect to it. The color editor simply removes this class
now to get an inert color swatch.
This is more flexible and lets us avoid referring to the
GtkColorEditor type in the theme.
It works just as well here as it does in the file chooser, and
this lets us unify the right-click and long-press behavior a bit.
We used to switch directly to the editor on long-press, now we
can show the popover, just as we do on right-click.
The last change accidentally removed the later restore, and
left the earlier, so we ended up with a restore-save sequence.
Thankfully, GtkStyleContext warns about this.
We want to render a background *and* the current color (if there is
one).
This also adds a custom function gtk_render_add_content_path() which
adds the path of the current content area to a cairo_t.
This adds a CSS box (complete with padding and border) for the icon. The
box is even drawn when no icon is present. Use the ".image" as the style
class here instead of -active-color-badge.
Use this box to draw the circle around the selection icon in Adwaita.
- gtk_style_context_get_background_color()
- gtk_style_context_get_border_color()
Those functions shouldn't be used anymore, because they don't represent
anything from the CSS styling we support. The background color often
isn't used due to background images and there are actually 4 different
border colors (1 for each side) - if there isn't also a border image in
use.
GtkGestureSingle::button is set to 0 on the multipress gesture, as several
buttons are managed by that gesture. Also avoid some extra lines of code
setting what nowadays are default values.
https://bugzilla.gnome.org/show_bug.cgi?id=734285
Add left/right/top/bottom style classes according to which edge(s)
of the progressbar the progress is adjacent to. Only for a fraction
of 1.0 will we set more than one edge.
Mainly doing s/TARGET/BUBBLE/ on the fully ported widgets, but GtkTreeView
where the double click handler has moved to GTK_PHASE_TARGET so it runs
parallelly to the still existing event handlers.
