| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
The new list view is going to be GtkColumnView-based, so it's going to
share some code with the GtkGridView-based view.
In order to avoid code duplication and still keep the NautilusFilesView
class agnostic of the widgets used by final classes, create an abstract
NautilusListBase class.
But this abstract class needs to interact with the item widgets, which
are going to be different between views. To resolve this, an abstract
NautilusViewCell class is created for the item widgets, which is also
going to be used for the new list view column cells.
Also, bump GLib version requirement now that we use GSignalGroup.
|
