| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
We used to refresh the app chooser list when we allowed for the
"Set Default" or "Reset" buttons. Now we only changed the defaults
*after* clicking the "Open" button. Refreshing the list could
change the selection and cause incorrect behavior.
|
| |
|
|
|
|
|
|
|
|
| |
Nautilus opens folders natively regardless of the default file type.
Don't allow users to change the default association for a folder
which would otherwise give a false impression.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2413
|
|
|
|
|
|
|
|
| |
We are only changing the default after clicking "open" based on the
design. Resetting the default used to make sense when it has a
dedicated button, but it no longer makes sense. Remove the "reset"
ability by setting the GtkSwitch as insenstive for the current
default and only taking action if the switch is active and sensitive.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2417
|
| |
|
| |
|
|
|
|
|
| |
The translatable string is not new, it was simply lost in the rebasing
process leading to commit dd407da7da81cbc02a3e8ec1a03f447cea0ac65f
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Was spamming warnings on list view.
Left over from c60d3099edca0558601c50c32f7307a26dda2532
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
We need this for the description within the app chooser.
If we are working on multiple files, set to NULL.
|
|
|
|
|
| |
Make default title "Open File" or "Open Folder" if it's a folder.
If we are acting on a mix of items make it "Open Items"
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Also drop GTK dependency, now that GTK is no longer used in our API.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2135
|
|
|
|
| |
We use GtkSortOrder internally only, it's not meant for extensions.
|
|
|
|
|
|
|
|
| |
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 don't want menu items to create their own windows in our process.
This helps with the effort to de-GTK-ize libnautilus-extensions API.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
GdkPixbuf is enough here.
|
| |
|
|
|
|
|
|
|
| |
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 meant to replace the existing GtkWidget-based solution.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/2365
|
|
|
|
| |
Because we don't have a column header-specific context menu.
|
| |
|
|
|
|
|
|
|
|
| |
This change was to be included in d7b03656210d5feb300d5df74db9cd4601306991
Probably a rebase fail on my side.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2401
|
|
|
|
|
| |
Because menu item is "Compress..." and we don't offer option to create
non-compressed Archives.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Resolves https://gitlab.gnome.org/GNOME/nautilus/-/issues/2207
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Show a bottom bar at small sizes, while hiding the start
and end children.
|
|
|
|
| |
Same rationale as previous 2 commits.
|
|
|
|
|
| |
Same rationale as last commit, except this control is independent from
the window slot, so it doesn't require any property binding.
|