Since the function is usually called from GtkWidget::drag-{begin,end} handlers,
taking a GdkDrop does not work, especially given that
::drag-action-requested is emitted without checking the type.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1220
The previous attempt at removing configure events entirely
was causing some dialogs not to show up under Wayland.
Presumably due to ordering issues with emitting ::size-change
out of the backend.
Instead, keep configure events in the event queue, but handle
them on the gdk side. This keeps the ordering intact, while
still removing configure events from the api. The dialogs
show up now.
The opaque region is only set when the background color is opaque. So
we need to do something about it when the background color changes.
However, in the case where a size allocation is going to happen, we
already do this update in size_allocate(), so in that case avoid doing
it twice.
Instead of instantly invalidating, we now cache the old render node and
do the update in an idle handler.
While that gives us a 1 frame delay, it avoids all the tricky things
like queueing resizes while resizing or queueing draws while drawing.
The only remaining issue (and a *big* one at that) is that a nested
widget paintable will now cause the widget to snapshot its previous
render node when creating a new one. And that one will snapshot its
previous render node, and that one will...
And nothing so far breaks this recursion.
This is still fallout from the bin_window removal. We aren't moving the
GdkWindow/GdkSurface anymore so we have to account for the scrolling
ourselves.
Since those are widgets and widgets need to be size-allocate'd properly,
we need to queue an allocate, as well as actually add the hadjustment's
value to the column x position.
Fixes#1202
The purpose of a searchbar is to start a search on visible widgets when
a key is pressed. Starting a search on e.g. a stack page that is not
visible at all is not very useful.
... if none of the debug displays have any debug flags set. This way, we
can ignore the first parameter to e.g. GTK_DISPLAY_NOTE, which is
usually a call to gtk_widget_get_display.
Before this patch, gtk_widget_get_display was the slowest part of
gtk_widget_query_size_for_orientation.
The min size on the oriented axis used to come from style props with
default values in the source file, used if the theme did not provide a
min size in CSS. When the style props were removed, so was any notion of
a minimal size for proressbars' main axis, meaning that now progressbars
without expand or any other source of min size were just tiny specks.
The right place to do that was always the theme, so in our themes now,
fix that by copying the old default values for the style properties; see:
https://gitlab.gnome.org/GNOME/gtk/issues/1191#note_259393https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/gtk/gtkprogressbar.c#L92
The result should be the same in that (A) the min size is now what it is
in GTK+ 3 & (B) an app/user can override the theme exactly the same way.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1192
(A) Put a space in "scrolled window" like the other doc comments
(B) Say "i.e." rather than "ie."
(C) Fix grammar from "makes [...] exactly reaches" to "exactly reach"
This is to go along with the newly introduced GdkDrop.
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
If we check it too early, we will not unset priv->draw_neeeded, which
will then cause queue_draw() calls to not have an effect later. And that
causes changes in opacity to not register.
Closes#1180
Binds this property to the button's label, allowing a model button to
have text with markup.
This will be convenient for buttons like 'Online Accounts <sup>↗</sup>'.
When deciding whether or not to emulate a press event, we're translating
the last event coordinates and mutating the given event structure
unconditionally.
We should modify the newly created GdkEvent copy, since it's what we're
going to use when emitting the press event.
This avoids mutating a constant GdkEvent and global state, and also
avoids a compiler warning.
The idea is that GTK+ 4 will be an epoch, API-wise.
Everything that was around for 4.0 has been there
since the beginning of the epoch and doesn't need
markers.
If the parent get_preedit_string implementation returns a nonnull
zero-length string, then we ignore it, which is almost fine. We have to
free it, though.
Fixes#1174
Expanders used to be 16px high. With the move from the gtk2 rendering
to gtk3 rendering they shrunk to 12px, making them hard to see, because
it's now the icon which is 16px high and the icon contains transparent
borders.
This makes the HighContrast theme use 24px icons instead, to restore
16px expanders. This may expander some containers a bit.
Closes#1046
GtkTextHandle was neglected by whoever removed the ::draw signal,
leaving it entirely broken. Update to using GtkGizmo so we can
implement snapshot of text handles.
Input has received a revamp too, handling is done through a
GtkGestureDrag and coordinate calculations simplified by storing
the delta to the hotspot on ::begin instead of ::update, as this
value is constant throughout the gesture. Widget state management
on crossing events happens implicitly, so no longer needs to be
done here.
Last but not least, CSS has also been updated so handles are
rendered at the correct size and proportion, and with the padding
that code expects of it.
Set up a gesture on the sidebar rows to detect pointer clicks on
it. The row DnD management has been moved to the row widget itself,
it makes more sense even if the drag is began from the sidebar widget.
We still need a drag gesture both on front (capture) and back (bubble)
to handle dragging from both the GtkWindow widget and chrome in the
headerbar. But we can do it through 2 drag gestures, instead of special
event handling code.
This has been broken since we switched key event delivery to follow
the same semantics than pointer/touch. There, GTK+ grabs will influence
the topmost widget during event delivery, rendering the toplevel
unable to handle key navigation. The toplevel must handle those key
events in an explicit manner then.
We don't render the keyboard focus rectangle yet, but I assume that's
something else.
Use an event controller on GtkFontChooserDialog, a nice side effect
is that we can use gtk_event_controller_key_forward() and
gtk_search_entry_set_key_capture_widget() instead of passing events
around for dialog search.
Instead of doing all handling manually in the ::event vfunc,
set up drag/multipress gestures on icon images, and implement
emission of ::icon-press/release and DnD there.
As a side effect, the GdkEvent field in ::icon-press/release
signals has been dropped. Callers that might be interested on it
may still use gtk_get_current_event*().
This isn't really necessary, if keyboard focus forcibly goes somewhere
else we will get ::grab-notify, which is sufficient to deactivate the
button again.
Selected rows in tree views in HighContrast have a background colour the
same or nearly as the normal text colour, so we cannot let entries in
such rows have transparent backgrounds, or the text inside the entry
becomes nearly or totally impossible to see.
Dodge this by giving entry.flat inside treeview and with :focus the
$base_color, which is different from the text & so lets that be seen.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/125
The else case was wrongly resetting the accessible description on the
primary icon, which might not exist and can therefore cause a crash.
https://gitlab.gnome.org/GNOME/gtk/issues/1160
The claimed status check should happen after ::end is emitted,
as the gesture may deny the sequence that much late. In this
case the event should keep propagating.
https://gitlab.gnome.org/GNOME/gtk/issues/1159Closes: #1159
We are poking again into the event propagation machinery, which
expects events in toplevel coordinates. Since we can't fetch the
original event back at this point, translate the coordinates
back to the toplevel so the emulated press ends up in the right
place.
https://gitlab.gnome.org/GNOME/gtk/issues/1159Closes: #1159
In particular, this patch removes:
gdk_surface_get_events()
gdk_surface_set_events()
gdk_surface_get_device_events()
gdk_surface_set_device_events()
Event masks so far still exist for grabs.
Otherwise gcc complains when we use these as arguments to g_new() on
32bit architectures with:
../gtk/gtkcomposetable.c: In function ‘gtk_compose_table_list_add_array’:
/usr/include/glib-2.0/glib/gmem.h:217:10: warning: argument 1 range [2147483648, 4294967295] exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
__p = g_##func##_n (__n, __s); \
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmem.h:279:42: note: in expansion of macro ‘_G_NEW’
#define g_new0(struct_type, n_structs) _G_NEW (struct_type, n_structs, malloc0)
^~~~~~
../gtk/gtkcomposetable.c:851:22: note: in expansion of macro ‘g_new0’
gtk_compose_seqs = g_new0 (guint16, length);
^~~~~~
/usr/include/glib-2.0/glib/gmem.h:96:10: note: in a call to allocation function ‘g_malloc0_n’ declared here
gpointer g_malloc0_n (gsize n_blocks,
^~~~~~~~~~~
When a remote instance of a GTK application implementing the Startup
Notification protocol gets spawned it will pass the startup sequence
ID as "platform data" to the main instance. Thus, we need to make sure
that the startup sequence gets completed in that case, since the remote
instance won't do it by itself, since it won't map any top level window.
Checking for this "platform data" in the implementation of the after_emit()
virtual method in the primary instance should be a good place to do so, since
the existence of such data proves that a remote instance has been spawned.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
The DESKTOP_STARTUP_ID gets cleared early after the process is spawned,
meaning that it's too late at add_platform_data() to pick it up and send
it over to the primary instance, as it will be always unset at that point.
To solve this, we use the new gdk_display_get_startup_notification_id()
method to pull the startup notification ID for the application, if present,
out of the display and pass it over to that primary instance.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
check_dir_mtime() is called by ftw() and is given
the real stat struct, not its glib version (which may
or may not be the same as "struct stat").
This is irrelevant for MSVC (it has no ftw()) and
works correctly for MinGW-w64 (which declares stat
structures correctly). If mingw.org complains, add
a special ifdef for it later.
Any data that is later fed to graphene must be
allocated with proper alignment, if graphene
uses SSE2 or GCC vector instructions.
This adds custom array code (a streamlined copy
of GArray with all unnecessary bells and whistles removed),
which is then used for the state_stack instead of GArray.
There's also a runtime check for the size of GtkSnapshotState
itself being a multiple of 16. If that is not so, any array
elements past the 0th element will lose alignment.
There are probably struct attributes that can
make GtkSnapshotState always have size that is a multiple
of 16, but we'll burn that bridge if we cross it.
and gtk_image_set_can_shrink().
Images are meant to always be icon-sized, they can never shrink below
that.
And images are icons, so they are meant to be square. If they are
not, we pretned that's by accident and keep aspect ratio.
This commit introduces GtkPicture, which is supposed to complement
GtkImage.
GtkImage will be adapted to always display an icon, while
GtkPicture displays regular imagery.
Instead declare a priv local. We should do this even if we don't remove
the priv pointer from GtkWidget entirely, just to stay consistent with
new code we introduce.
Otherwise, requesting a min size in em where the equivalent in px had a
fractional part would lead to the widget getting allocated 1 too few px.
You could see this in the CSS property vs. allocation in the Inspector.
Note that margin/border/padding are left alone: the rationale is that we
do as browsers do, and Benjamin said we already do that for those,
whereas his tests on min-(width|height) showed otherwise. My subsequent
analysis indicated it to be far less clear-cut than that, but he remains
unconvinced that we should ceil() all the things! So just do these ones.
https://gitlab.gnome.org/GNOME/gtk/issues/1088
Causing a grab in the handler for ::pressed by, e.g., popping up a
context menu will cause the gesture to be canceled and, subsequently,
::end and ::released to be fired, all while the button is still
physically pressed. That results in no event being available to the
::released handler and garbage coordinates, given that
gtk_gesture_get_point() returns FALSE.
Emitting ::released can be avoided by checking the return value
gtk_gesture_get_point().
Querying the event sequence of a gesture will always yield NULL for
non-touch events, but passing NULL in to calls to
gtk_gesture_get_last_event() is a perfectly valid use case.
That code branch is meant to check for key events, seems obvious we want
GDK_KEY_PRESS, not GDK_BUTTON_PRESS (which also broke the branch right
below).
Makes us all able to dismiss popovers again.
We can just as well use notify::has-focus for the purpose of
focus tracking, and we can at the same time avoid emitting the
deprecated AtkObject::focus-event signal.
:climb-rate is not about what you get when you single-click on a button,
as this implied: it's what happens if you hold down a button or a key.
Fix the description of @climb_rate to new(), and while here, mention the
key in the blurb of :climb-rate itself.
The last round of patches to get the desired direction of value move in
response to scrolls/keypresses on scales had the inadvertent side effect
of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
already a collection of hacks, add another so that fix only holds if the
instance is a GtkScale, since that is what those patches were aimed at.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
We were mutating the list while iterating over it. This was not a
problem before since remove_controller just set the controller pointer
to NULL instead of actually removing it from the list of controllers.
We can avoid a signal connection per event controller (and the
EventControllerData struct) since every event controller knows the
widget it's attached to.
GtkTextView scrolls to the insertion point when the text
buffer signals a paste is done. This is wrong when there
are multiple views on the same buffer, and the paste
happened in another view.
To fix this, flip the handling of the scroll_after_paste
boolean to only be TRUE if we know that we want to scroll.
The gtk_app_chooser_dialog_set_heading() function do emit
notify::heading. Since the setter simply calls the function,
the setter itself shouldn't emit a notify signal by itself.
The bubble_timeout_id was reset only on some special case.
And so warnings were shown when the source is being tried
to be removed with the already removed id.
Fix this by unconditionally resetting the id on start of the function.
A container node inside another container node doesn't make a lot of
sense, we can instead just use the parent container node and add the
child container node's children to it directly.
gdk_win32_keymap_check_compose() shouldn't be called for
non-W32 displays (i.e. when using broadway or other backends
that could be made to run on Windows).
We no longer set the widget on construction, but instead require an
explicit call to gtk_widget_add_controller().
This way, the reference handling becomes explicit and bindable.
Because gtk_widget_add_controller() is (transfer: full), we don't
even need to unref the controller after adding it.
And we don't need to keep track of it, because controllers get cleaned
up by GtkWidget.
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
