Saving a file includes choosing a filename. But yyping a filename
would conflict with type-to-search on the "selector" view.
So, introduce a new "namer" page in NautilusFileChooser.
Part of: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3401
The new design for Network view uses an address entry bar which is
similar to the one from Other Locations view. Instead of reinventing
the wheel, let's salvage some code.
In addition to formatting the code to nautilus style, this also makes
a couple of visual changes to match the design requests.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/2785
Now that NautilusPlacesView is gone, we don't use this anymore.
But there is quite a bit of recycleable code here. So, let's take this
out of the build pipeline in order to disassemble it freely.
It's going to be replaced with a new Network view.[0]
For now this removes only the direct support in nautilus code proper.
The code imported from GtkPlacesView is kept to be recycled for a new
purpose.
[0] https://gitlab.gnome.org/GNOME/nautilus/-/issues/2785
Instead of special casing the NautilusFile for the starred:/// URI,
give it a proper display name as part of a new specialized subclass.
This is prepared to handle more cases, like the upcoming Network view.
Set correct icon and remove tooltip for cancel
button when an ongoing operation is canceled
Use cancel button icon "emblem-ok-symbolic" instead of
"object-select-symbolic" since it is more correct in the current
use case as suggested by @snwh
Use tooltip "Completed" for cancel button instead of
"Operation Finished" since it is more friendly in this context
suggested by @snwh
Set "Completed" as a translatable string credit to @coreyberla
Part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/3294
Move date formatting to new date-utilities file, to allow it being
called from other places too. The new file also handles reacting to
changes in date related preferences.
More functionality will be added/moved to this file in a future commit.
Turn the file duplication testing code into a dedicated unittest.
Unittests are more straightforward to run than the eel self-check
mechanism. This also allows dropping eel dependencies and reduces
the size of the file-operations file.
The concrete duplication syntax is abstracted away with a macro for
better readability of the comparisons.
We were subclassing from GtkBox and then, list-view created a
list-view-column-editor which subclassed from AdwWindow to add
the column-chooser. It's a lot of extra code / complexity for something
that is only used in list-view. This also allows us to directly
use column-chooser within list-view.
Also drop the list description label, in preparation for the switch to GtkListBox.
Currently trash infobar contains actions for restoring files and
emptying trash.
This is misusing of the GtkInfoBar, as it should only be used to present
some kind of status message, and having so many different buttons for
actions is uncommon and resulted in https://gitlab.gnome.org/GNOME/nautilus/-/issues/2096
To fix that, remove the trash infobar altogether, with intention of
rolling it into special-location-bar, as it will only have 1 button.
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.
When choosing to open a file in another application, the user may want
to set it as the new default.
Currently we require going to the Properties, which is not intuitive,
and one may think it's going to affect only one file.
Introduce a GtkAppChooserDialog replacement which provides the means to
set as default and reset as part of "Open with Another Application...".
Compared to the Properties "Open with" tab, the "Add" action is not
present, because opening the file with an app adds it implicitly. The
"Forget" action is not included either because it lacks its "Add"
counterpart and because such fine grained control is not essential. We
have Reset anyway.
GtkTreeView, while still available in GTK 4, is more limited in some
more specialized situations which we have been relying on, such as
drag-and-drop and high DPI icons.
It's also been our long desire to adopt GListModel-based list widgets
in order to unlock features and bugfixes which would have been
basically impossible to do with GtkTreeView.
We are thus dropping GtkTreeView for good and adopting GtkColumnView.
The new implementation is radically different; almost no code remains
from the old implementation. However, the new implementation has full
feature parity with the old one with two exceptions:
1. Expand subfolders as a tree: WIP in another branch.
2. Performance for large number of items: WIP branch in GTK.
Same as the old implementation, it still lacks drag-and-drop support,
which is yet to be reimplemented for GTK4.
The new implementation also implements new features which were but
a dream in GtkTreeView:
- Rubberband-selection.[1]
- Empty space inbetween and around the list of items to open context
menu, start rubberband, drop items, clear selection...[2,3,4]
- Rows highligh on hover, distinguishing them from background space
and serving as a reading aid instead without separator lines.[5]
- File names in search results and recents are no longer squashed by
the "Original location" column containing long paths. Instead, the
original location is runs parallel to the filename.[6]
- With the location column gone, the size column can be displayed
again in these two special locations.
- Full-text-search snippets no longer compete for horizontal space
with filenames, but are displayed as accent-colored subtitles.[7]
- Filenames are ellipsized at the middle, not to hide important
details at their end.[7]
- Sort order can be changed from the view menu, as in grid view.[8]
- Per-folder sorting is shared with the grid view now, fixing an old
inconsistency.[9]
- A starring animation ☆★
Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/320
[1] Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/200
[2] Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1929
[3] Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1476
[4] Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1764
[5] Fixes https://bugzilla.gnome.org/show_bug.cgi?id=744405
[6] Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1411
[7] Fixes https://bugzilla.gnome.org/show_bug.cgi?id=619760
[8] Fixes https://bugzilla.gnome.org/show_bug.cgi?id=142495
[9] Fixes https://bugzilla.gnome.org/show_bug.cgi?id=45659
Following the view rename, also rename the item widget.
Upcoming NautilusViewClass subclasses are going to follow the same
Nautilus*Class naming pattern.
Also add missing copyright notice with SPDX licence id.
GtkPlacesSidebar is a public GTK 3 widget, but private in GTK 4, so we
need to have the sidebar in our own codebase if we are to keep using it.
Extend the script already in use for the places view and use it to copy
the places sidebar and its dependencies and patch it as necessary.
Also, construct it from code, because this in-tree places sidebar cannot
be used in a GtkBuilder UI template.
The new grid view has reached feature parity with the canvas, if we
ignore drag-and-drop and clipboard support (which would need to be
reimplemented in GTK 4 anyway) and performance scalability (which is
a problem of GtkFlowBox and solvable by using GtkGridView in GTK 4).
The canvas view relies on extensive custom implementation for layout,
drawing, input handling, accessibility, etc., which would be too
hard to port to in GT1K4.
Furthermore, most of its features, such as support for manual sorting,
haven't been used since the "icons on desktop" feature has been taken
out from this app. We are actually using a swiss army knife for a job
where we only need a single blade -- a simple pocketknife would do!
Therefore, we say goodbye to this seasoned veteran widget, who has
served us for 2 whole decades.
Now the Ctrl+S dialog is being built using the
GtkBuilder API, Now it's styling and can be
handled in the XML UI definition. The UI definiton
needs to be handled manually as Glade doesn't handle
the implementation of the GtkDialog used here.
Modify the dialog to be built declarartively to enhance maintainability and aid
in porting to GTK 4.
This introduces a minor UI change with the 'Replace'/'Rename' and 'Skip'
buttons swapping places, with the suggested action now the endmost button as
is standard practice.
Keeping with the direction of preferring declarative UI definitions.
Also, it will help with porting to GTK4.
While we are at it, adopt HdyWindow for rounded corners and make
the label not bold and allow it to wrap (to avoid making the dialog
too wide with some translations).
The code is quite stable and this is basic functionality which is going to be
better in Nautilus rather than relying on extensions, given the quite bad
extension system Nautilus has.
This will also help with the port to gtk4, so we rely in yet another important
extension providing properties pages (which in turn export gtk3 widgets).
