Between the time this was scheduled and the actual call, the file
may have been removed from the directory and, as such, from the
view, and the only reason the row, item and file weren't destroyed
is because we kept a reference to the row. But it's invalid to
access the file now.
We want to stop being a NautilusFilesView subclass.
Emit signals instead and have NautilusFilesView handle them.
The logical flow is the same.
Also simplify on_row_expanded_changed() while touching it.
That's the job of NautilusFilesView, and, incidentally, it already
handles it. So, it may as well take care of everything.
However, NautilusFilesView has no access to the expander, so the
NautilusNameCell itself takes over that job. As it should.
Multiple subdirectories may be loading at the same time, so it's
incorrect to set .subdirectory_loading to FALSE when one of them
is done loading.
Instead keep a list of subdirectories which are loading.
nautilus_view_get_location() doesn't transfer a reference, but we've
been unref'ing the location since ee00f7c2f3
Use nautilus_file_get_location() instead, which transfers a reference.
This removes the last usage of NautilusView interface methods on self,
which prepares us to stop inheriting from NautilusFilesView.
It requires a NautilusFilesView parameter, and we are going to stop
being a NautilusFilesView subclass soon.
So emit a matching signal and have NautilusFilesView handle it by
swapping itself in as the first parameter.
We are including files-view-dnd.h for a single method of which we are
the single user. And nothing about it requires NautilusFilesView at all
if we ignore the awkward and pointless slot getter.
We want to stop inheriting from NautilusFilesView, which means we are
not going to be a NautilusView implementation either.
So we must create the selected files list ourselves.
(Conceptually, code dealing with NautilusFile objects should be moved
to files-view.c, but that's not a show-stopper at this time.)
The only usage is to clear selection.
We can use GtkSelectionModel API for that purpose instead.
This reduces the reliance on NautilusView methods, because this
class is not going set to stop inheriting from NautilusFilesView,
which implements that interface.
NautilusFilesView can reuse the code from the previous commit instead.
Now we don't implement any NautilusFilesViewClass fvunction anymore,
which gets us closer to the plan from https://gitlab.gnome.org/GNOME/nautilus/-/issues/3042
This was an oversight in [1] and causes the pipeline not to run for
release branches, but for any other branch. Fixed by inverting the
condition.
[1] ecac11569e
While the code is imported, indentions on the current files are a mess.
This makes it more difficult for contributors to get things right, so
incude these files in the uncrustify script and format them.
Binding the slot's location to the page's tooltip doesn't work for
search because the location will change only when the search begins,
but not for any subsequent updates to the query. Instead, listen
for changes to the slot's title, and use the existing logic to
actually update the tooltip
This wraps a linear search in an apparently simple call, which invites
lazy coding and invites future performance regressions.
This is not to say there is no need to iterate the model linearly. But
when doing so, it's best to do it explicitly, in a for/while loop, to
make it easy to spot performance issues.
The `.pending_scroll_to` file is only ever relevant if we don't set a
`.pending_selection`. This only ever happens when we are asked to
handle a file which extracts.
In that case, there is no reason not to additionally select it as well.
The extracted files are going to be selected afterwards anyway.
This allows us remove some now-dead code. There is no optimization
here though, because nautilus_files_view_call_set_selection() runs
a linear search not unlike nautilus_view_model_find().
Just like its recently removed sibling, it's utterly broken. The
but is similar to the one reported on [0], except it happens on
reload instead of view mode switch.
Likewise, it relies on intensive fragile computation, because GTK
doesn't give us the visible range in item positions.[1] There is
no hope to fix this without GTK help.
This is only used by the slot when reloading and if nothing is
selected. The cases where this is most benefitial are very long
lists, but these take long to load and the scroll happens at the
end mostly as a surprise.
This is one less virtual method for NautilusListBase to inherit.
[0] https://gitlab.gnome.org/GNOME/nautilus/-/issues/3034
[1] https://gitlab.gnome.org/GNOME/gtk/-/issues/4688
After the last commit, get_first_visible() file is only used for
thumbnail prioritization logic. prioritize_thumbnailing_on_idle()
is very inefficient and over complex as it constantly iterates
through the bound items to see what is visible.
Instead, let's rely on an GTK implementation detail: list widget
children outside the scrolled viewport area are not mapped. With
this assumption, we can connect to ::map in the cells needing a
thumbnail.
The only catch is that it maps more items initially than are
visible, so also connect to ::unmap revert the prioritization for
items that are mapped and immediately unmapped.
The last commit introduced restoration of selection from history.
When going back, we want to select the parent (or other ancestor),
which is usually, but not always, the saved selection. Not to change
the pre-existant behavior, ensure the ancestor selection always
takes priority over the requested selection when going back.
For one, the restored scroll position is not faithful to the original
scroll position: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3034
Instead, restoring selection provides more benefit. Save selection as
a vector of URIs (storing NautilusFile lists would be a hassle, because
it requires listening for ::changed in order to remove a file when it is
marked as gone...)
Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2818
More often than not, there is a legitimate reason for the
requested selection not to be found.
E.g.: You are on list view with expandable folders enabled,
and a file in an expanded subfolder is selected. When you
switch to grid view, it tries to restore the previously
selected item, but it's not found anywhere anymore.
The next commit is going to introduce another such case.
Let's admit it: it's utterly broken.[0]
It relies on intensive fragile computation (shared with thumbnail
priorizatio), because GTK doesn't give us the visible range in
item positions.[1] There is no hope to fix this without GTK help.
This is only used by the slot when switching view mode anyway, and
only if nothing is selected. The cases where this is most benefitial
are very long lists, but these take long to load and the scroll
happens at the end mostly as a surprise.
This is one less virtual method for NautilusListBase to inherit.
[0] https://gitlab.gnome.org/GNOME/nautilus/-/issues/3034
[1] https://gitlab.gnome.org/GNOME/gtk/-/issues/4688
With one exception, it's called right after setting selection, so we
can simply do both things at the same time with set_cursor().
The exception is revealing the item for the popover to attach into,
for rectangle computation, which is easily solved by having the
reveal (i.e. scrolling) be done by the rectangle computing function.
This is one less virtual function for NautilusListBase to inherit,
as part of the plan from https://gitlab.gnome.org/GNOME/nautilus/-/issues/3042
Mostly avoiding overhead of g_list_length() when we only need to know
whether the selection is empty or contains a single item. But also in a
few cases avoid allocating a file list at all by checking the selection
bitset directly or doing it only if needed (like the debug case).
While touching it, also unexport a function which is no longer used by
subclasses and remove its obsolete documentation comment.
This removes another usage of nautilus_view_model_find(), which
is a performance liability.
Also reuse this helper function in another place where we were
already doing the same thing.
