There is no need to treat this as a programming error. Simply don't
validade filename without a directory.
This is going to be needed by the FileChooser in SAVE_FILE mode, if
neither the client app nor the user has set a target directory yet.
This property is going to be set to TRUE by the upcoming FileChooser.
If turned on, the validator will still provide feedback on duplated
names, but it will accept them nonetheless if otherwise valid. It's
up to the FileChooser to confirm the user wants to override the
existing file.
Instead of using out parameters and local variables, store booleans
in the instance structure.
This is required to introduce more nuanced behaviors, like allowing
to override existing files on FileChooser dialog.
Both require a button for the view.new-folder action.
The formet additionally requires hiding the window close button,
because design calls for an explicit Cancel button instead.
They are hidden on narrow browser windows. And wide windows end up
having whitespace when the pathbar reaches maximum width.
But on FileChooser they are always visible and cause the toolbar not
to fit the minimum width on narrow windows.
Let's just remove the separators along with the boxes packing them
with the history and view controls.
Currently, it caches the view selection through bindings.
Unfortunately, this cache may get out of sync with the view, because
NautilusView:selection is a file list that's generated on-demand, and
NautilusView::notify:selection is unreliable. E.g. when the view
switches to a new location, it empties the model, which effectively
clears selection, but this is not notified as a selection change.
Making NautilusView:selection's notifications reliable is going to
require quite a bit of refactoring, so that's for another time.
Drop the binding and proxy the selection property without caching it.
Instead of reimplementing GtkFileFilter, which conveniently takes
the GVariant format from the FileChooser portal interface, let's
wrap it with a filter of our own which translates NautilusViewItem
into a dummy GFileInfo.
To make them reusable in the upcoming FileChooser window.
Reuse the slot.open-location and add macro for actions with arguments.
The "win.go-home" action is preserved for the pad controller, which
doesn't support passing parameters to actions.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3413
This is going to allow the upcoming FileChooser portal implementation
to attach its window as a modal dialog to client applications, even
if they use different display servers (X11 and Wayland).
Make it a private static library to be used in commming commits.
Contrary to upstream, we use the imported *.impl.* definitions.
For convenience (not to move a lot of meson code around), define
the HAVE_GTK_WAYLAND and HAVE_GTK_X11 in config.h instead of
compiler flags.
These are copied from [xdp-desktop-portal], to avoid adding it and all
its dependencies as buildtime dependencies of our own (and to the
flatpak manifest).
[xdp-desktop-portal]: https://github.com/flatpak/xdg-desktop-portal/
`x11_interop` is the symbol of a global variable, but gets reused for
a local one.
We should try to keep this code in sync with xdp-desktop-porta-gnome
so, instead of chaning the symbol, ignore the compiler error.
This is code copied from xdg-desktop-portal-gnome repository today[0].
We need it to implement the FileChooser portal ourselves.
It's not included in the build yet, as it needs modifications first.
[0] b92a8cc5f6
When asked to open the URI leading to an archive file, the slot
marks the file for extraction as soon as the view is loaded.
In FileChooser modes we wouldn't extract anyway, since activation
is handled by the slot. But it would lead to other unexpected
results, like immediately sending the file to the portal as result.
This is really a corner case but let's avoid it anyway.
The view handles activation through mime-actions.c functions, which
allow, among other things, opening files in other apps.
We don't want that in the FileChooser modes. Opening folders is okay,
but what we want to do when double-clicking a file depends on the
exact mode and the filters that apply.
Prepare to handle activation at a higher lever: the expected action
will be implemented by the upcoming NautilusFileChooser, by handling
the new NautilusWindowSlot::activate-files signal.
While the FileChooser will not want to launch files in handler apps
on activation, it still needs to activate items that open in view.
For regular folders it would be trivial, but for mountables it would
have to reimplement logic that's already present in mime-actions.c
In order to make it possible to use `nautilus_mime_activate_files()`
from the FileChooser to open items in view, we need to stop relying
a NautilusApplication method, because the upcoming FileChooser will
not be a NautilusApplication window.
Since we already pass the slot as a pointer, we can just use the slot
method directly, which produces the same effect here anyway.
Disable 35 actions, to ensure they cannot be activated (e.g. by
keyboard) even if not found on context menus:
"paste"
"paste_accel"
"create-link"
"create-link-shortcut"
"new-folder-with-selection"
"open-with-default-application"
"open-with-other-application"
"open-current-directory-with-other-application"
"open-item-new-window"
"open-item-new-tab"
"cut"
"copy"
"create-link-in-place"
"create-link-in-place-shortcut"
"move-to"
"copy-to"
"delete-from-trash"
"star"
"unstar"
"delete-permanently-shortcut"
"delete-permanently-menu-item"
"permanent-delete-permanently-menu-item"
"remove-from-recent"
"restore-from-trash"
"paste-into"
"extract-here"
"extract-to"
"compress"
"send-email"
"console"
"current-directory-console"
"properties"
"current-directory-properties"
"run-in-terminal"
"set-as-wallpaper"
Additionally disable "new-folder" in OPEN mode, as it is still wanted
in SAVE mode.
Note: "open-scripts-folder" in theory should also be disabled, but it's
not worth the effort, as there is no shortcut, no menu item, and no harm
(it would just open a Files application window).
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3414
The slot is already a construct property, so it makes sense to
complete the initialization on `constructed()` instead.
This paves the way to do rely more on the slot during construction.
The slot and its internals are going to be reused by the upcoming
FileChooser window, as part of a FileChooser portal implementation.
However, some behaviors and UI elements are going to be different.
So, the slot needs to know on which mode to operate from the start.
There are 3 FileChooser portal methods[0]:
- OpenFile
- SaveFile
- SaveFiles
But OpenFile has 2 boolean options ("directory" and "multiple) which
mean there are actually 4 modes:
1. select single file
2. select single folder
3. select multiple files
4. select multiple folders
As such, we have 6 new modes to support, in addition to the "browse"
mode (i.e., business as usual).
[0]
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.FileChooser.html
The "start-icon" property is already set with the property bind between
the bookmark and the row in the same function, and the GIcon reference
generated by calling `nautilus_bookmark_get_symbolic_icon()` is not
dropped.
nautilus-bookmark-list is sending changed signals in the same callstack
where the rename button is pressed, which is before the popover is
unmapped. And thus is causing the sidebar to rebuild the rows, destroying
the row before the unmap callback is called on the row.
Change the binding of the signal to the lifetime of the row instead of
binding it to the sidebar.
This fixes a crash when renaming bookmarks.
This was a small oversight in [1] that causes crashes when trying to
drag and drop new bookmarks after opening a new window and closing
the old one.
[1] 26480b7017
Instead of sending a signal for NautilusWindow to open the requested
location, send it directly. This will make it easy to reuse the sidebar
in the upcoming FileChooser dialog.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
The commit[0] which introduced this comment aimed to fix a bug which was
caused by double-clicking a folder on the view.[1]
This change was ineffective as per later comments on that bug report,
which is not surprising because the change was wrong: this code path was
(and still is) used only for changing locations using the pathbar and
sidebar. The bug happening with double-click on the view is uses another
code path, in mime-actions.c, which has later been patched[2].
So, let's remove the wrong FIXME comment and effectively revert [0],
which, as expected, doesn't introduce any bug in my testing.
[0] 49c03251ee
[1] https://bugzilla.gnome.org/show_bug.cgi?id=756499
[2] 755c771058
Instead of having NautilusWindow relay the change, have the sidebar
talking directly with the window slot.
This prepares the sidebar to be reused in the upcoming FileChooser
dialog which is not going to be a NautilusWindow.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
The public GtkPlacesSidebar in GTK3 couldn't make assumptions about a
place that was private to nautilus, so it would emit a specific signal
instead of regular ::open-location.
Now that it's all nautilus-internal, there is no reason not to use the
regular ::open-location signal. This way NautilusWindow doesn't have
to handle the special signal, which makes the upcoming FileChooser
implementation simpler.
Part of https://gitlab.gnome.org/GNOME/nautilus/-/work_items/3431
Around the 3.0 release, the sidebar featured section headers and there
was a section whose header was "Computer".
We still carry that name in an enum symbol. It makes no sense nowadays
if you don't know the history. So, let's rename it to the name by
which it is informally called in current design mockups.
