This is the first step towards refactoring how widgets deal with event
controllers.
In the future, the widget will treat controllers the same way it treats
child widgets:
1. The controllers will be created without a widget.
2. There will be gtk_widget_add/remove_controller() functions to add
or remove controllers.
3. The widget will hold a reference to all its controllers.
This way we will ultimately be able to automate controllers with ui
files.
to retreive paper size specific hard margins and use this
to set the hard margins in the print context.
(modified by Marek Kasik <mkasik@redhat.com>)
https://bugzilla.gnome.org/show_bug.cgi?id=686109
gtk_get_current_event() returns a new reference to the event, it should
be freed across various return branches to avoid the event leak, or we
just fetch the little stuff we're interested in.
And of course, gsk_render_node_get_name() is gone, too.
The replacement is of course debug nodes.
As a side effect, GskRenderNode is now *really* immutable.
.linked assumes the container is a GtkBox, which is documented as never
flipping children in RTL, so :first-child is always the left child, etc.
GtkBox does that by reordering its CSS nodes when the direction changes.
But most widgets don’t do that, so :first|last-child are 1st/last ADDED
and swap sides in RTL. GtkPathBar is so, and ignoring that in our themes
meant that in RTL, its left/right buttons got each other’s borders. Yuk!
This patch adds the groundwork for supporting widgets like that, via the
%linked_flippable placeholder, and applies that to override buttons in
filechooser .path-bar.linked > button
so that the correct borders get applied to those buttons when using RTL.
Note that I select only PathBars within a FileChooser because we also
have NautilusPathBar, which also uses widget.path-bar – but *does* flip
its nodes for RTL already, so letting that get affected broke it again!
https://bugzilla.gnome.org/show_bug.cgi?id=772817
See the previous commit.
There may be other cases of these being swapped by Gadget conversions,
but hopefully someone else will find and fix those before I have to…
Close https://gitlab.gnome.org/GNOME/gtk/issues/200
Otherwise, if the Popover is destroyed before the MenuButton, the latter
still had a non-NULL but invalid instance and tried to use it in dispose
Close https://gitlab.gnome.org/GNOME/gtk/issues/199
Use g_signal_connect_data() instead of g_signal_connect_object()
to make sure the callback gets disconnected when the data object
is destroyed. This avoids problems in garbage-collected bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=789215
Well, they don't require a redraw of the widget, because the widget
itself didn't change.
They require a redraw of the parent, because that now displays the
widget in a different position.
And this means we can keep the cache of the widget's render node.
My fishbowl numbers are through the roof^W water surface. Vulkan gets
4000 now.
Due to the few type checks in gtk_widget_get_display(), it was the
slowest part of a call to gtk_widget_query_size_for_orientation if the
in case of a cache hit.
We pulled out the bounds calculation for performance reasons, but the
caller can't know how to properly compute them. Inside gtk+, we can do
that but it's not good enough for public API.
The GVariant we are getting here might not be coming
from GTK+, but rather from some other source. Best to
be forgiving and deal with missing data without crashing.
This was causing the GTK+ portal backends to crash on
print requests from Qt.
It might happen otherwise that a change is recorded in between the
widget dispose and finalization, causing a crash when setting
the visible name for the GtkStack (as that will be NULL at that point)
This will be used in subsequent commits to fix the sign by which the
value is changed in response to directional scroll or keypress events.
The idea is: you have a movement to make – in the form of a delta that
follows widget directions, i.e. −1 means left or up, +1 means right or
down – and you want to know whether that delta needs to be inverted in
order to produce the intuitively expected directional change of :value.
The existing should_invert() is not sufficient: it just determines
whether to invert visually, but we need more nuance than that for input.
To answer that – while not doubling up the work for scrolls and keys – I
add a helper should_invert_move(), which considers other relevant state:
• A parallel movement on priv->orientation should just use the existing
should_invert(), which already worked OK for this case (not others).
• Movements on the other orientation now depend on priv->orientation:
◦ For a horizontal Range, always invert, so up (i.e. −ve in terms of
widget coords) always means increase value & vice-versa. This was
done in get_wheel_delta(), but move it here for use with keys too.
◦ For a vertical Range, ignore :invert as it’s only relevant to the
parallel orientation. Do not care about text direction here either
as RTL locales do not invert number lines, Cartesian plots, etc.
This returns TRUE if the delta should be inverted before applying to the
value, and we can now use this function in both scroll and key handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=407242https://bugzilla.gnome.org/show_bug.cgi?id=791802
If widgets want to clip things, they now need to do it themselves.
By not taking care of clip, we avoid the need to track clip. And by not
tracking clip, we can avoid all unnecessary cache invalidations that we
were doing for render nodes whenever the clip changed.
And when you are scrolling, the clip changes *a lot*.
priv->button is a guint, but we assigned it to a local gint.
gtk/gtkmenushell.c:734:37: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
if (button && (new_button != button) && priv->parent_menu_shell)
^
...from CellRenderer::start-editing, to point people in the direction of
info about the lifecycle of the Editable and how to do generic setup.
https://gitlab.gnome.org/GNOME/gtk/issues/154
Drop the line copied from .activate(), replace it with a description of
what this method actually does, and explain what a NULL result means.
https://gitlab.gnome.org/GNOME/gtk/issues/154
* Note in the intro that we're really thinking about temporary widgets
* Mention a gotcha regarding GtkEntry and how ::focus-out stops editing
* Give some examples of what you'd want to do in ::editing-done
* Be a bit more precise about what ::remove-widget represents
* Summarise the lifecycle between Renderer/Editable in .start_editing()
* Emphasise again there that this should be viewed as a temporary widget
https://gitlab.gnome.org/GNOME/gtk/issues/154
GTK does use libintl directly (in gtkmain.c, for example) and thus
needs to be linked to it (if found and/or needed).
Previously we most likely were getting libintl from glib, but
that stopped for some reason. Either way, explicit linking is
the right thing to do here.
Instead of going through an ancillary script to strip away the
`WL_EXPORT` annotation from the generated code, we should bump up the
required version of Wayland, and use the `private-code` argument for
wayland-scanner, which does the right thing for us.
Instead of connecting to / disconnecting from the frame clock, do it
inside the vfuncs next to changing the priv->realized boolean.
This removes a race between those 2 cases that could cause child
widgets' unrealize handlers to reconnect this widget to the frame clock
because it was still marked as realize when the widget had already
disconnected from the frame clock.
Fixes#168
But in turn, also allow it to work on widgets with their own surface.
This way, we can chain up from everywhere and won't have to export
gtk_widget_set_realized().
