Comment # 12 on bug 1074138 from Stefan Hundhammer

(In reply to Adam Majer from comment #11)
> > Our proposal for a workaround: Do not install those that you don't want.
> 
> That's a poor workaround. Another would be to just re-install the system?

If Debian is your preference where you cherry-pick everything you like and
ignore everything else, maybe...


> Somehow this works just fine in Aptitude on Debian with even more packages
> than Leap. 

Aptitude is an NCurses (text-mode) utility, so this is beyond the point you
previously made about Qt's model/view.

OTOH Synaptic would be the Qt counerpart on Ubuntu (and Debian? not sure), and
it doesn't have half (more exactly a quarter) of the features that our Qt
package selector has. As a matter of fact, when I start that thing, it
typically takes 10-20 seconds until it is finished building some index that
always seems to be outdated.

So, it seems to me you are clutching at straws, relying on others just not
knowing that stuff.

Also, how many packages exactly does Debian (or a recent Ubuntu) have that
might possibly be displayed in any such "all packages" list? I could not find
any numbers on the web.


> But it doesn't work with Yast2 Qt GUI *or* console text UI.

That should give you some hints that it's not a problem of how that list is
implemented in our YQPackageSelector, but that it's rather a problem of the
sheer mass of packages that accumulated with all that splitting up large
packages into tiny bits and pieces.

Please remember that I do have a solid basis for comparison. When I started the
data model in QDirStat, first I did it without sorting, and it was really fast,
even with 400.000+ items in the tree. When I then introduced sorting with the
thing that Qt recommends, the QSortFilterProxyModel, performance broke down
completely because obviously it prefetched and sorted the complete tree in
advance before showing *anything*. So I did that part myself (and this is when
things get really hairy because the relevant Qt classes don't support you at
all with this), and I only got snappy performance back because of deep internal
knowledge of my data structures, lazy sorting and relying on not too many tree
branches being open at the same time.

But this would not work at all with such a package list. In effect, such a data
model would have to keep a duplicate list of all the packages in the current
view and sort it according to the current sort column. Not only does that mean
duplicate at least all the pointers, it's also that old computer science
problem of doing an efficient sorting; O(n*ln(n)) is the best you can achieve
(e.g. with a heap sort which does not easily degrade in the pathological case).
But one way or the other, you have to sort the complete list in the model to be
able to create a QModelIndex which you need if you create your own model.

And that's not much different than what the simplified QListWidget /
QTableWidget (the convenience classes on top of QListView with a
QAbstractListModel or QTableView with a QTableModel) do.

And if you now write that you see poor performance with the same "show all"
view in the NCurses version as well this just proves the point.

So let's please stop this pointless discussion. We have too many packages now
to handle them efficiently in such a "show all" list. So, if people insist that
this is now too slow, the only real solution we have is not to offer that view
anymore. Is that what you want?

We ALWAYS offered that only with the caveat that there would be a heavy
performance penalty. This is why we don't simply show that complete list be
default upon startup, why it's somewhat hidden away. If you cannot accept that
limitation, don't use it.

The recommended way of all the use cases you mentioned is different for a good
reason; I described it above in great detail.