On the verge of UI freeze, spliting this among previous commits is not
possible, unfortunately. So, this packs a few changes at once:
* Avoid double scrollbars. The GtkScrolledWindow is preserved for
future use when we get rid of GtkAppChooserWidger, but otherwise
it doesn't scroll.
* Add a separator above default switch row.
* Make the switch row and make the whole row clickable.
* Fine-tune margins.
Set the switch to active when the association is set as default
and inactive when it is not set as default (also a way to remove
the default association). Add a label for the switch with a
subtitle indicating the content description.
If we are acting on a single item or multiple items that all have the
same mime type, set to true. This will be used for setting the title
and ability to change file type association.
We don't want extensions to inject random inconsistent widgets
into our window.
If there are good reasons for this, in the future we can introduce a
new model-like API instead of a widget-based one.
We want to control the layout of the window, not having extensions
injecting their own widgets.
This also avoids future breakage when porting to newer versions of GTK.
Starred status can be perceived as a property, also in grid view there
is no visual indication or easy way to change it.
Furthermore, we are to remove the star action from the view menu.
This is not necessary per-se, because it's the default activation
keybinding. But in order for it to appear in the context menu as a
the suggested keyboard shortcut, we need to bind it to the menu item
action.
It's been identical to background context menu so far because
the later was inaccessible in list view if scrolling.
But in the new list view, background context menu is allways
accessible. so we can deviate now.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2355
We show Templates and Scripts submenus conditionally, using the
hidden-when=action-disabled attribute, by assigning a dummy action
which we can set as active or inactive as fit.
However, this causes criticals when the popover menu is destroyed:
(org.gnome.Nautilus:21502): GLib-CRITICAL **: 16:15:32.870: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed
Indeed, submenus are not supposed to have actions. There is a
"submenu-action" but it's for a different purpose.
So, instead of controlling the visibility through a dummy action,
set or unset the "hidden-when" attribute to control its visibility,
the same way we already do for sort menu items.
In GTK3, we would reuse the same GtkMenu, but update the model.
With GtkPopoverMenu, this is creating duplicate stack page each time
our submenus are updated. And it turns out we update templates and
scripts menu a lot of times, on directory monitor callbacks! Besides
warnings, this causes increasing memory consumptions.
Additionally, reusing the same popover while updating the model causes
the old model do be temporarily displayed when the popover is opened,
which sometimes even causes the popover to resize and jump around.
This is obviously bad.
Avoid both problems by creating a new popover menu every time we open
the context menu. The old one is destroyed (by unparenting) right
before this. (Not on GtkPopover::closed, because this would be too
early and actions would fail to activate!)
Since we don't need to deal with the automatic spacing from
GtkHeaderBar, we can take advantage of GtkRevealer to get
a smooth transition for the button's visibility. This also
gets rid of a flicker and warning from GTK.
GtkHeaderBar automatically provides spacing for its children.
However, this spacing doesn't play well with hidden revealers.
In order to not have double spacing, this commit creates GtkBoxes
at both ends of the toolbar, and moves the margins to the children.
In order to adapt to narrow window sizes, we need to be be able to
show the same controls in different places, but we don't want to
duplicate the code or the UI definitions.
Thus, we should encapsulate the code and logic we need into distinct
reusable components.
Start with the back and forward buttons, along with their context menu.
They will update their state properly through bindings without needing
to call any functions ourselves.
