Rename the surface getter to peek, following other render
node getters, and make the surface-based constructor private,
since it is not something we want to encourage.
Update all callers.
The gtk_tools variable is an array of arrays; adding a new element
requires to maintain the same type, or we'll get a build failure when
we try to extract the newly added element.
Add the necessary machinery into the Meson definition files so that we
can build for Windows.
Since we don't have Wayland or X support for our use case here, disable
them once we know that we are building for Windows, as they are
(otherwise) enabled by default, and enable the items that need to be
built for Windows builds.
Exclude gtk4-launch from Windows builds as that is something that
is not supported on Windows.
As we won't have gio-unix on Windows, and PangoFT2 is optional, don't use
fallbacks for them when we are on Windows (but do use fallbacks for
gio-win32, as it will be used).
Also, clean up meson.build a bit as we can just force-include
msvc_recommended_pragmas.h from GLib since we depend on GLib, and so we
can handle these warnings from msvc_recommended_pragmas.h instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
What is missing is the "allocation" part of x/y coordinates. Since
gtk_entry_realize doesn't call gtk_widget_set_window(priv->text_area),
the coordinates returned by gdk_window_get_origin don't include it.
This patch fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=784509
Bug 737175 aimed to ensure that scrolling up on a horizontal range would
result in its value increasing, as that’s what users intuitively expect.
However, its commit 416c370da1 meant that,
if the event gives scroll deltas, we inverted our delta unconditionally.
So it broke horizontal scrolling: scrolling left moved the slider right…
We must only invert if using dy as delta. dx already has the right sign,
so inverting it was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=788905
The gtk_widget_get_display call in this if statement is showing up in
profiles. It ends up walking up the hierarchy to the toplevel to get its
GdkScreen, etc. so it is relatively costly. Avoid that call in most
cases by first checking if the RESIZE debugging is enabled for any of
the displays and only then checking if it is enabled for the widget's
display.
If the call to set_parent() failed, we were still adding the child to
the internal list of children, despite that it was not really added.
That meant we could later try to do invalid stuff with that non-child.
Fix that by asserting and giving up if the child that the user is
attempting to add is already parented.
https://bugzilla.gnome.org/show_bug.cgi?id=701296
The language is useful for parsing tools, such as that of gtkmm, which
otherwise assumes these are C snippets and elides them from its
generated documentation.
It was used to mark css properties that affect widgets with text, but it
caused unnecessary invalidations. E.g. 'color' was marked as
AFFECTS_TEXT but changing just the color of a label should not
automatically queue a resize, which is what the code in
gtk_widget_real_style_updated does.
Replace this flag with GTK_CSS_AFFECTS_TEXT_SIZE and
GTK_CSS_AFFECTS_TEXT_CLIP, which GtkWidget can use only if the widget
actually has text.
After a gesture first claims, and later rejects a touch sequence,
a press event will be propagated further along. However propagation
got messed up since we only emitted as far as the toplevel.
It does not hurt us to keep middle clicks doing the same
as shift-primary clicks. This makes the transition from gtk2
less painful in terms of muscle memory.
https://bugzilla.gnome.org/show_bug.cgi?id=787669
Clarifies the code and helps catch invalid enum values before they
propagate further. Also add a comment about why two seemingly legitimate
values are not handled there (they’re handled higher up in the file).
Coverity CID: 1457700
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788787
gtk_box_pack_end will put the label child at the right side of the label
(in LTR orientation), but we want it left, directly next to the icon.
Also remove the spacing from the box child as this is a theme thing.
~Company ╡ so TL;DR: we put the static style in the cache, but then
⤷ ╡ compute a child style from the animated style in the cache
⤷ ╡ and we put the child style also in the cache (because
⤷ ╡ it's not animated)
⤷ ╡ then we run the animation, but reuse the cache every time
⤷ ╡ for both child and parent
⤷ ╡ so after the animation is done, we end up with a cache that
⤷ ╡ has the correct static style for the parent but an
⤷ ╡ incorrect static style for the child
⤷ ╡ because that static style was computed from the
⤷ ╡ initial animated style
This fixes https://bugzilla.gnome.org/show_bug.cgi?id=763517
An empty container has the same effect as transparency
with the cairo renderer, but creates black with Vulkan.
To avoid this, explicitly use a transparent color node.
This fixes the css blendmode example in gtk4-demo with
the Vulkan renderer.
As Timm Baedert pointed out, the previous fix made the
menubar go on top of popovers, which is just wrong. Instead,
make gtk_window_snapshot handle all direct children of the
window, taking care to stack popovers correctly.
This is important since _push_state returns a pointer into a GArray
which could be invalidated and point to garbage after the subsequent
push_state call.
This is used for example in the source tab of gtk4-demo.
It broke because GtkScrollbar no longer is a GtkRange,
but rather has one. So we need to forward the signal.
It was selecting paned separator, which means any separator at any level
of descent within a paned, including the toplevel container in GEdit.
We need to be more specific and only select the relevant separator that
is the direct child of the paned. This is what Adwaita does.
https://bugzilla.gnome.org/show_bug.cgi?id=788573
Nulling priv->button in _unset_tree_view() is asymmetrical: we create
it via init(), not _set_tree_view(), so we shouldn’t null in the latter.
Worse, doing so manifests in criticals + a SEGV easily with basic use of
testtreecolumns, removing the TVC from a TV then trying to add it to one
Finally, the wrong null-out meant dispose() failed to unref the button,
so it leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=728452https://bugzilla.gnome.org/show_bug.cgi?id=788614
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
GtkCellArea uses event coordinates (thus in treeview relative
coordinates), but calculations used to happen in bin window coords.
We can just offset the cell area by the bin window, fixes cell
renderer activation and edition.
If the column is not clickable, it may make some sense to stop
event propagation here for button events. However motion events
should be left alone.
Fixes treeview column resize pointer cursors, since that's
implemented up the bubbling phase in the treeview.
The operations rely there on bin window relative coordinates, but we
are receiving GtkTreeView relative coordinates there. Fixes clicking
on treeview expanders, which was offset by visible headers.
-Wint-conversion is important because it checks casts from ints to
pointers.
-Wdiscarded-qualifiers is important to catch cases where we don't
strings when we should.
The border and icon highlight are useful feedback that was defeated by
CSS precedence. It worked for .titlebuttons due to their implementation,
but the same was not true for custom .flat buttons. This makes it so.
https://bugzilla.gnome.org/show_bug.cgi?id=788580
When the window was backdropped, they suddenly regained their border.
This was clearly not intentional or of any practical use to anyone.
Shuffle around some selectors so that the backdrop ones do not override
the flat ones and make the borders magically reappear when backdropped.
Note that, whereas standard titlebuttons get the border on :hover, other
.flat buttons in the headerbar do not. That should probably be fixed too
https://bugzilla.gnome.org/show_bug.cgi?id=788580
They were hard-coded to a transparent black, but that is our bg colour
in HC Inverse, so windows stacked on top of each other or a dark
background blended together into a mush.
Fix this by making the $_wm_border* colours relative to the fg colour,
so that HighContrastInverse gets borders that are transparentised white.
https://bugzilla.gnome.org/show_bug.cgi?id=788575
A missing decoration selector meant that we got a solid black background
behind the rounded corners of the dialog.
Copy the equivalent code from Adwaita, including nicely rounding the
focus outline too (& sorry, but this needs more newlines to be readable)
There were various problems, like only selecting on .tooltip and not the
widget node tooltip, not being specific enough for tooltip.csd, etc. So,
specific theming was absent, and default popup window styles got applied
This commit copies in the better working tooltip CSS from Adwaita, but
applies a couple of changes to make it work better in the HC themes:
• Reduce the transparency of the tooltip, so we achieve higher contrast
• Drop the black text-shadow, as it is not useful on this more black bg
Note: we may then need to re-add some of this to the .tooltip class. But
it is unclear what needs done there. While Adwaita is not doing it, we
are better not to confuse by keeping it in HC only; we should try to be
as close as possible, to make it easier for HC to keep up with Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=769879
We need
.window-classes decoration
but within the decoration parent selector, we were doing
&.window-classes, which gave us
decoration.window classes
We need to fix this by selecting on .window-classes &
https://bugzilla.gnome.org/show_bug.cgi?id=788496
n_attach_points is the result of g_strv_length(): the index at which the
string vector ends in NULL. So by definition, when i == n_attach_points,
string[i] == NULL, and there is no need to check for the latter. The
fact that we did appears to confuse static analysers, as the dereference
and index check were inverted from what would normally be safe. We could
reverse them, but we may as well just remove the unnecessary NULL check.
https://bugzilla.gnome.org/show_bug.cgi?id=788458
This gives consistent behavior with e.g. Qt, Mozilla's suites and
LibreOffice (with non-truly native backends like "gen" and "gtk",
but unlike "gtk2" and "gtk3" ones that probably use true GTK menus).
This behavior is expected by at least some accessibility users, and
it seems good to behave like other common applications and toolkits
in this area. There should be no issue in doing so either for current
users, as it only enters the submenu instead of not doing anything.
https://bugzilla.gnome.org/show_bug.cgi?id=778811
ComboBox and TreeMenu warned in the doc for :row-span-column that the
value must not exceed :wrap-width, but :wrap-width does not interact
with the number of rows; it’s the :column-span-column that’s relevant.
Also: Warn that spans must be > 0 for rows too, and that column spans <=
:wrap-width are also not useful for items at menu column positions > 0.
Finally, refer to items having spans, not values, as we were already
talking about values in the model (and rows in the menu).
Instead of creating one GPtrArray per GtkSnapshotState and saving nodes
in there, create one GPtrArray per snapshot and assign a
start_node_index to every GtkSnapshotState as well as a n_nodes variable
so every state knows which nodes belong to it.
It's not a GtkCssGadget anymore, it doesn't have any properties or
signals either and it's not public. Further, its lifetime is very clear
the way it's being used inside GTK+.
This showed up in profiles in certain scenarios, so export a
_get_n_shadows getter instead and let callers provide a sufficiently
large allocated array of GskShadows, which we can use with
g_alloc/g_newa.
The GtkFlowBoxCreateWidgetFunc type lacked GObject Introspection
annotations for its arguments. This made gtk_flow_box_bind_model()
unusable from Python as the callback function would be passed useless
values.
The annotations that I've added match those of the similar callback
type GtkListBoxCreateWidgetFunc.
https://bugzilla.gnome.org/show_bug.cgi?id=780758
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
Those worked similarly to those in GtkFlowBox, but would additionally
handle "active" state for child rows. Simplify this to just enabling/
disabling active state on gesture press/release, we don't get the
nice state updates when hovering around with a mouse button pressed,
but the rationale from flowbox applies here, and makes a nice cleanup.
They just maintain priv->in_button and widget state up-to-date, this
basically matters during user interaction, and is already maintained
in the gesture ::update handler. This seems to be sufficient.
Those basically controlled priv->active_child_active, which would
1) trigger a redraw when the pointer enters/leaves it, and 2) ensure
that press/release happen on the same child for it to be activated.
The former is not necessary, and the latter can be simplified by
just checking again the child on the coordinates given by the
::release gesture handler. This makes all enter/leave/motion_notify
event handlers unneeded.
All kinetic scrolling initial velocity calculations are now
taken from the scroll controller. The handling of timeouts
to snap back when overshooting has been also made to just
apply on devices that can't emit ::scroll-begin/end.
This is a GtkEventController implementation to handle mouse
scrolling. It handles both smooth and discrete events and
offers a way for callers to tell their preference too, so
smooth events shall be accumulated and coalesced on request.
On capable devices, it can also emit ::scroll-begin and
::scroll-end enclosing all ::scroll events for a scroll
operation.
It also has builtin kinetic scrolling capabilities, reporting
the initial velocity for both axes after ::scroll-end if
requested.
This change is made for consistency, it doesn't make sense to expose
one-way propagation, as it can only break expectations from GTK+. This
function might be made entirely private in the future, but it still
makes sense to do this in one go for our internal usecases.
This will allow further cleanups and optimizations in capture/target/bubble
event delivery. For simplicity, ATM every widget will receive its own
GtkEventControllerLegacy, it could be desirable to add finer control over
this in the future, so widgets that fully use event controllers for input
management can do away without this legacy piece.
