Sort packages by clicking Name, Version, Reason, Repository, IsInstalled, and package size

[oech3]

yay -Ps or paru -Ps sorts packages by size.
It would be nice if it sl possible also for pacfinder

Packages are sorted by name by default.
Sorting by Repository,IsInstalled is useful only for user overlaying repositories such as testing,CachyOS,ALHP.

[stevenbenner]

Yes, that is something I want as well.

I actually had sorting of packages by columns working in an pre-release version of the program. The package list is built with a GtkTreeModelFilter to support filtering by the various options in the filters list on the left. Unfortunately, when I put a GtkTreeModelFilter on top of GtkTreeModelSort the program became very slow. Absurdly slow, actually. As in it would take 5 to 10 seconds after clicking on a filtering option before the list would be shown. So I had to remove the sorting ability, as the package status filtering is the core feature of this program and sorting was a secondary feature.

Maybe I was doing something wrong. Or maybe those two classes just weren't meant to work together. But I couldn't find a satisfactory solution when I was first developing PacFinder.

The most likely solution is for me to build my own GtkTreeModel that implements both filtering and sorting directly - avoiding the n^2 (or more, apparently) work of layering the classes provided by Gtk.

Another thing worth looking into is GTK 4. All of the tree stuff was reworked in version 4, so there may be a more performant solution available with the latest toolkit. Version 4 has also become widely adopted now - which it wasn't when I created this program. A GTK 4 migration is a good idea, but kind of a big and high-risk project.

And, while it's not immediately relevant, GTK 5 is now on the way. It looks like they have all but scraped and rebuilt the whole tree view system, which should be... interesting.

[oech3]

Is pre(background) sorting at runtime with O(n log n) possible in principle (not by API of GTK)?

[stevenbenner]

Yes. That's actually how it is done now. The package list is sorted alphabetically when it is fetched from libalpm - on startup or refresh.

The behavior of the package list control itself is based on the model though. If I remember correctly, the GtkTreeView needs to be fed a GtkTreeModelFilter to have filter events (gtk_tree_model_filter_refilter()) or GtkTreeModelSort to be sortable (have sort arrows on column headers). - or a model that offers both sort and filter (which doesn't exist in GTK 3).

But I get what you're suggesting; Just do the work on the data before feeding it into a model. That might be a good idea - though probably the opposite or pre-sorting, instead pre-filtering. So that a sortable model is bound to the control and it offers sorting column headers.

Filtering is currently done with the GtkTreeModelFilter row filtering. I could indeed implement filtering by instead purging the model, constructing a new filtered list, and then repopulating the model. That is a fairly expensive operation and requires me to handle some additional memory management, but it might actually be an easier option than constructing a custom model that inherits the correct stuff and integrates with the GtkTreeView.

I'll refresh myself on how the tree view control works. It's been a long while since I dug into this problem.