| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Toggling sort directories first in list view causes a crash.
This is a regression in commit b9ac68eb6fb1f7aa5f815f9b15cd789758d62cba
gtk_sort_list_model_set_sorter() first unrefs the old sorter, then refs
the new sorter. The crash happens because the new sorter is the new
sorter. It gets destroyed by the unref, and therefore we crash when
trying to ref a destroyed object. (It's arguably a GTK API bug too.)
The solution (from our side) is for us to hold a temporary reference to
keep the object alive.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an item is moved, we are still showing it in the old location as a
regression caused by commit 510a4202d25b82323a1307918b382aab603190eb
With the introduction of tree model, we maintain multiple list stores
(one for each TreeListRow when the TreeListRow is a directory) and the
item is associated with a directory store upon creation by checking
nautilus_file_get_parent(). When removing an item, we again find the
directory store to remove from, by checking directory_reverse_map for
the parent file.
But, when an item has been moved, the parent file is no longer the same
as when it was added. This means we try to remove the file from the new
parent instead of the old one.
Fortunately we already have a solution for this from the old list view:
NautilusFilesView.remove_file() gets passed the directory to remove the
file from. Let's use it instead of the current parent.
Heavily based on diagnosis and commit message from patch by Corey Berla
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/2784
|
| |
|
|
|
|
| |
Before 1a1f2b50778e03ac14bea7ee684bb9bddc563bc1 we only returned
non-NULL items in get_items_from_files. Fix this regression
that causes crashes in some situtations
|
| |
|
|
|
|
|
|
|
| |
This is going to allow us to reuse the model for a GtkColumnView-based
list view with expanding trees support.
As documented, GtkTreeViewRow:item may be NULL when the item it held
is destroyed. So, we must take care to handle the NULL case when
expected and also warn and return when not expected.
|
| |
|
|
|
| |
The view doesn't see any difference yet, but this prepares for
tree expansion support later.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a required step in order to use GtkTreeListModel later.
GtkTreeListModel doesn't work well when its internal models get
resorted: it assumes the items are gone, not reordered, causing
the row objects to get destroyed and the view to lose track of
things.
This might not be as efficient, but we've got no other option
other than implementing a custom tree list model...
|
| |
|
|
|
|
|
|
|
| |
Every time we set a selection, ::selection-changed is emitted twice,
first from gtk_selection_model_set_selection() and then from
gtk_selection_model_selection_changed. Remove the second call.
This essentially reverts 0e4265e97907fdee34e0d28d17f518e50318e9af
The issues mentioned in that commit are no longe reproducible.
|
| |
|
|
|
|
| |
This avoids future emissions of a "changed" signal during destruction.
Also fix setter not to connect to signals when the sorter is NULL.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It gets called at a time when the new files haven't made it into the
view mode yet. So, we create a pair of dummy items for the sorter to
work on, and then throw them away.
Creating and destroying object instances at every step in the sorting
algorithm wastes a lot of cycles while loading large folders, with
visible performance impact.
So, instead of sorting before the view items are created, do it when
they are created, right before they are added to the model's internal
list store.
|
| |
|
|
|
|
|
|
| |
Newer compiler versions (i.e. Clang 15) failed to compile nautilus,
because the declaration did not match the function definition.
See: https://reviews.llvm.org/D122895
Fixes #2378
|
| |
|
|
|
| |
We are attempting to clear the signal after the sorter is already
freed. Clear the signal first.
|
| |
|
|
|
|
|
| |
This is both shorter and more aligned with the convention to call
GListModel elements "item".
Also add missing copyright notices with SPDX licence id.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Also expose it as a property.
This prepares for GtkColumnView sorting.
|
| |
|
|
|
|
|
|
|
|
| |
When view-item is disposed (i.e. switching from grid view to list view)
assertions are failed when attempting to free self->internal_model.
The GtkMultiSelection self->selection_model took ownership of
internal_model and thus already freed it on dispose. Increase
ref count when creating internal_model.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2148
|
| |
|
|
|
|
|
|
| |
Due to a bug in the docs, I've been under the mistaken impression that
g_list_model_get_item() didn't pass a reference to the caller.
https://gitlab.gnome.org/GNOME/gi-docgen/-/issues/127
Use scoped autocleanup to fix this.
|
| |
|
|
|
|
|
|
|
|
| |
Sometimes selection changes are not notified, which causes regressions:
* `nautilus --select /path/to/file` fails to select file
* going to parent folder fails to select child folder we came from
As we implement GtkSelectionModel ourselves, we can and should notify
these changes even if the internal GtkMultiSelection doesn't.
|
| |
|
|
| |
This is a requirement for GtkGridView.
|
| |
|
|
|
| |
GtkGridView is going to rely more heavily on item index instead of
pointer to widget which might be recycled for another item.
|
| |
|
|
| |
It's functionally equivalent, but more compact.
|
| |
|
|
|
|
|
|
| |
It costs us very little because we already hold an internal model, so
it's easy to wrap it.
This makes it a starting point for some day using GTK4's list widgets,
which take a GListModel.
|
| |
|
|
|
| |
It’s not done in some places. After this commit, there still might be
some missing, but this is all I gathered in a short amount of time.
|
| |
|
|
|
|
|
| |
The only use of nautilus_view_model_set_items() has been replaced with
nautilus_view_model_add_items().
Related: https://bugzilla.gnome.org/show_bug.cgi?id=795307
|
| |
|
|
|
|
| |
A copy paste error from the set_items function.
https://bugzilla.gnome.org/show_bug.cgi?id=780380
|
| |
|
|
| |
Better performance, code design and fixes some issues.
|
|
|
After all the rework on the window slots, views, and splitting
the desktop, we are finally able to add a flow box based view for
Nautilus.
The GtkFlowBox is still not performance enough to be added as the
default view, not even as an alternative in the user preferences.
However, since the work on this is one of the biggest for Nautilus and
gtk+, the decision was to merge a prototype in order to open the
development, testing and iteration of the code in order to make it
good enough for, in a not so far away future, have it as the main view.
The work merged is not finished, and is an experiment and prototype in
more things than just the GtkFlowBox, we want to create a single shared
model with a complete MVC pattern between all the views. This will need
quite a few iterations to get it right, but once is done right, I hope
it's going to be good enough as an example to any application that wants
multiple types of views with the new widgets of gtk+.
This patch adds the GtkFlowBox view to be optionally used under a
gsetting called use-experimental-views, turned off by default.
|
