nautilus:wip/antoniof/update-starred-uris

Last commit made on 2024-01-12
Get this branch:
git clone -b wip/antoniof/update-starred-uris https://git.launchpad.net/nautilus

Branch merges

Branch information

Name:
wip/antoniof/update-starred-uris
Repository:
lp:nautilus

Recent commits

ddf6c86... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

view-model: Drop find()

This wraps a linear search in an apparently simple call. This invites
lazy coding and invites future performance regressions.

This is not to say there is no need to iterate the model linearly. But
if when do so, it's best to do it explicitly, in a for/while loop, to
make it easy to spot performance issues.

6ad4470... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

window-slot: Always select file to activate

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 e a file which extracts.

In that case, there is no reason not to additionally select it too.
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().

154c05c... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

files-view: Drop .get_last_visible_file()

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

97f6b8a... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

window-slot: Save selection on history, not scroll position

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.

Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2818

67e0038... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

files-view: Drop .get_first_visible_file()

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

e5f36ef... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

files-view: Drop .reveal_selection()

With one exception, the revealing 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

1394335... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

files-view: Drop unnecessary wrapper

Use compound literals instead. This simplifies the next commit.

0618029... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

files-view: Minor selection optimizations

Mostly avoiding overhead of g_list_length() when we only need to know
if the selection is empty or contains a single item. But also in a few
cases avoid allocating a files list all 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.

c93dbeb... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

list-base: Optimize get_first_selected_item()

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.

6b289f8... by =?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>

list-base: Stop implementing .scroll-to-file()

NautilusFilesView can just call the set_cursor() method instead.

There is a minor behavior change: now it sets focus in addition
to scrolling to the target file. It looks like a good change,
actually, because otherwise we would scroll to the position but
upon arrow key press jump to the start of the list...