It's a big performance drag to create many cells (and their associated
widgets) for columns that may never be shown. Only create cells
is the column is visible, and subsequently create/remove cells
when in column_set_visible.
The value property is only getting notified when it's unset
or when it's set from gdk_drop_real_value_async(). Make sure
to always notify :value when its changed
The term "cancelling" is used with GCancellable, a user clicking a close
button is not that.
User input is usually described as "dismissing", so we use that term.
A screen reader user is not interested in GTK internals, for example,
he does not care whether a button is an image button or not,
and a screen reader will report the fact that it is a button anyway.
Same applies for GtkEntry widgets, for example.
This actually is sufficient to fix gnome-control-center#2244.
And, according to the discussion in #5145, it should be fine.
ClutterInputFocus/GtkIMContext uses char based offset for
delete_surrounding, however, text_input_v3 uses byte based offset for
it. Currently only GTK with mutter can work correctly via text_input_v3
because they both forget to convert between char based offset and byte
based offset.
This commit fixes it in GTK by converting byte based offset to char
based offset with the UTF-8 encoded surrounding text.
Fixes <https://gitlab.gnome.org/GNOME/gtk/-/issues/4566>.
If the drag events are claimed by another gesture (e.g. a GtkDragSource
in an item widget), list base still commits a rubberband selection, for
a rubberband which wasn't even visible yet. This is a problem for the
GNOME Files application which needs both rubberbanding and drag-n-drop.
My previous fix[0] was enough for the case where the event sequence is
claimed right before the first GtkDragGesture::drag-update emission,
but it's useless if the event is claimed later (e.g. after the drag
treashold), because a rubberband already exists by that time.
Therefore, the complete solution requres checking whether the event
sequence is no longer being handled by our gesture, and commit the
selection changes only if it is, but otherwise cleanup the rubberband.
This is what GtkFlowBox does already, so let's do the same here.
[0] commit dc4540fae9
Dummy dependencies are not required to execute a subproject
automatically for providing a program, nor do you need to explicitly
call subproject() to do that.
A `[provide]` section in the wrap file is enough.
The tooltips from the Grid View & List View buttons are unnecessarily long and look different from the tooltips used in Nautilus.
This commit makes the tooltips to be consistent with Nautilus and, consequently, makes them shorter.
Accept labels can be used for additional context regarding
the purpose of a file. The old GtkFileChooser APIs allowed
developers to set it, but the initial FileDialog API was missing
this functionality.
This commit adds `gtk_file_dialog_set_accept_label ()` to
restore the missing functionality.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/5421
The EventControllerFocus on the list item, updates the list base focus
tracker and scrolled to position any time the list item enters focus.
This works when interacting within a single window, but has unexpected
results when changing focus between multiple windows.
Instead of using the focus controller workaround, just make
gtk_list_base_update_focus_tracker the set_focus_child vfunc
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5433
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5432
The path bar does a lot of manual management of buttons, mostly to
be able to show navigation arrows when there's not enough space to
show the full path.
Since the GTK4 migration, this is slightly broken in some cases, due
to the 'need_sliders' variable being always set to TRUE. Furthermore,
after the introduction of the Recent button as a special cased fake
root, the allocation of the buttons is generating warnings.
Reimplement the path bar as a GtkBox, inside a GtkScrolledWindow.
This mimics what Nautilus does, and allows us to make navigation more
predictable, and remove most of the complexity from GtkPathBar. It
also prevents it from generating allocation warnings.
The path bar itself now doesn't override GtkWidget.measure nor
GtkWidget.allocate; instead, it delegates layout to the GtkBinLayout
layout manager.
CSS is adjusted to account for the changed hierarchy of buttons.
It's positioned and looks exactly like the browse_toggle_view_button,
but due to the way things are organized, we cannot simply reuse that
button.
Add a clone of browse_toggle_view_button in the search entry page of
the toolbar stack. Make it toggle the same action as of the original
button, and bind the icon name and tooltip texts to it too.
Most of the pointer comparisons against 'browse_files_column_view'
should actually be performed against the current view widget. As
it turns out, it weren't that many places after all.
Add a grid view outside of the widgetry tree. The grid view mimics
the column view using bindings, so we only need to manage the column
view.
Also add a button in the path bar section to toggle the view. This
is handled as a new 'toggle-view' action in the file chooser.
The way switching between views currently work is by setting either
the column or grid view as the child of the GtkScrolledWindow. This
has the benefit of unmapping the unused view, which is nice and can
avoid some tricky situations with thumbnails.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/233
Notifications are not going to be emitted during the finalization, and
GObject will warn if you try to acquire and release a reference to the
notification queue when the reference count of an object has reached
zero.
Fixes: #5420
Recommend that scope implementations should fall
back to or derive from GtkBuilderCScope in order
to not lose GTK's type-guessing machinery.
Related: #5398
Nested async calls are always a challenge.
Hopefully, things are straightened out now,
and we report GTK_DIALOG_ERROR errors for
the cases we care about.
If the parent window of the button gets destroyed
while the dialog is open, we cancel the async op,
but we need to be a little more careful about not
stepping on glass.
If the parent window of the button gets destroyed
while the dialog is open, we cancel the async op,
but we need to be a little more careful about not
stepping on glass.
