Decoration node for drawing is used only for client side decorated
windows, but corners from opaque region is subtracted also for
normal windows.
Rename function to better reflect what it does and do not subtract
corners if decoration node was not used for drawing.
link target uses `$selected_bg_color` and `$selected_fg_color` for the
definition of some selectors (e.g. selected).
While `$link_color` and `$link_visited_color` are based on
`$selected_bg_color`, this does not seem coherent.
Replacing `$selected_*g_color` in link target style with link colors
defined in `_colors.scss file`.
We use a compilation symbol in our build to allow the inclusion of
specific headers while building GTK, to avoid the need to include only
the global header.
Each namespace has its own compilation symbol because we used to have
different libraries, and strict symbol visibility between libraries;
now that we have a single library, and we can use private symbols across
namespaces while building GTK, we should have a single compilation
symbol, and simplify the build rules.
Instead of loading the unflipped version first and then flipping it.
Don't do it in add_render_ops either but only in the function actually
adding the render ops for the nodes, since those frequently have
early-out conditions that don't need the vertex data at all.
The click gesture in GtkListBox is exclusively for primary button
clicks; this means we're never going to get a click from the middle
button. We need to use a separate GtkGestureClick controller for middle
clicks, in order to activate rows with the 'open-in-tab' flag.
Fixes: #179
Directly coloring labels can create a lot of unintended behaviors.
Unfortunately we can't avoid directly coloring `label:disabled` because
it can be used individually. This, however, tries to inherit color from
the parent element of labels wherever possible.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1643
The bug was introduced in commit:
9b7640b8 by Benjamin Otte, 2012-03-26 17:24:02
styleproperty: Make _gtk_style_property_parse_value() return a CssValue
In that commit, `values` changed from `GValue*` to `GtkCssValue**`,
but one `!G_IS_VALUE (&values[8])` was left untouched. As a result,
if `border` shorthand contains anything after color, it might crash,
depending on memory layout.
New test included.
Fixes: #751
- Propagate the error back to the parser, so we get a proper GError
instead of a g_warning().
- Connect closures by id, don't construct a name from the ids so that
glib can take it apart again.
gtk_builder_connect_signals() is no longer necessary, because all the
setup that made it necessary to have this extra step is now done
automatically via the closure functions.
This will be the future way to connect signals automatically (and be
used for other things, too).
For now, gtk_builder_connect_signals_default() is ported to use it.
This is pretty unused and gets in the way of the next steps.
A potential side effect is that for templates the widget was passed as
the user data argument. If that turns out to be important, we have to
special case that situation.
