Instead of passing the style declaration, take the node's style
declaration. Add arguments to allow overriding the state for the one
case where this didn't work.
The code is confusing the stylecontext=>node transition, so I'll remove
it.
WIth the recent introduction of the parent style cachen, I'm not sure
it's worth it at all. Some crude benchmarking suggests a slight speedup
when removing the cache.
So no guarantees about adding it back later.
- GtkCssWidgetNode
for style contexts owned by a widget
- GtkCssPathNode
for style contexts using a GtkWidgetPath
- GtkCssTransientNode
for nodes created with gtk_style_context_save()/restore()
The functionality of it is supposed to grow, so better put it in a
custom file early.
This is just a naive split so far, the next patches will split things
further.
The wl_data_source may be the clipboard's. Looking up the drag context in
order to get the display isn't going to fare well there. So, just use the
default display, and only look up the drag context when we know we need it.
https://bugzilla.gnome.org/show_bug.cgi?id=746386
This commit adds the GtkTextTag:underline-rgba and :strikethrough-rgba
properties and the necessary plumbing to apply these colors in GtkTextLayout.
With this change, you can alter the color of underlines including those
of type PANGO_UNDERLINE_ERROR.
You might want to alter the underline color to differentiate between
spelling and grammer mistakes. In code editors, it is convenient to
differentiate between errors and warnings.
Note that the GtkTextAppearance struct is public ABI and has no spare
room for new fields, so we are resorting to some tricky packing to store
the colors in the unused pixel field of the fg_color and bg_color structs.
This packing is accomplished by the macros in gtktextattributesprivate.h.
Signed-off-by: Christian Hergert <christian@hergert.me>
https://bugzilla.gnome.org/show_bug.cgi?id=402168
It has been a long-standing request to interpret scroll events
with Shift held down as horizontal instead of vertical, and
some applications are already doing this on their own.
https://bugzilla.gnome.org/show_bug.cgi?id=132197
This causes pixman warnings, or worse.
Clearly, something is not quite right here, if we end up
redrawing tabs at a time when the allocation is set to (1, 1).
For now, avoid straining the error handling in the lower layers.
https://bugzilla.gnome.org/show_bug.cgi?id=746301
On popover_unmap(), perform the gtk_widget_unmap() call last, so the
GtkWindowPopover data is ensured to be alive throughout the function
if the popover widget is destroyed right on ::unmap.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
This ensures the widget data stays live long enough to perform invariants
check after emission if the widget happens to be destroyed on a callback.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
We are testing -gtk-icon-style and assume the theme doesn't touch it.
But HighContrast forces symbolic icons. And that breaks the reference
images.
So explicitly set "requested" for everything.
Support scaling of cursors created from themes. The default scale is
always 1, but if the pointer cursor surface enters an output with a
higher scale, load the larger version of the cursor theme and use the
image from that theme.
This assumes the theme size is set to one that fits with an output scale
= 1.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
The setting of the the surface scale even when the surface is not
created from a surface was introduced due to a crash when getting the
buffers when dividing by the scale. The only reason I can see this is
that we get the buffer from a non-existing surface when the wl_cursor
has not yet been set.
Instead, use the name field to avoid trying to use the non-existing
surface, effectively avoiding the division-by-zero that way.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
