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.
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
Attached widgets inherit from the style of the widget they are
attached to. This can sometimes have unintended consequences,
like a context menu in the main view of gedit inheriting the font
that is configured for documents, or the context menu of the preview
in the font chooser coming up with humongous font size.
To fix this problem, we introduce a context menu style class
and use it for all menus that are used like that. The theme
can then set a font for this style class.
https://bugzilla.gnome.org/show_bug.cgi?id=697127
Prevent the new window dragging code from interfering with
selection of colors on button release, by handling button
presses we care about instead of letting them bubble up to
the window.
Partial fix for
https://bugzilla.gnome.org/show_bug.cgi?id=695493
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
Support long press for customizing, and short press for
selecting/activating. This is simpler than the generic
press-and-hold support in the multitouch branch; we don't
display any feedback, and the timeout is currently hardcoded
to 1 second.
Instead of having an input/output GdkWindow, make the widget no-window,
and use a separate input-only window for events, and paint on the parent
window directly.
