http://bugzilla.suse.com/show_bug.cgi?id=1074138 http://bugzilla.suse.com/show_bug.cgi?id=1074138#c13 --- Comment #13 from Adam Majer <amajer@suse.com> --- (In reply to Stefan Hundhammer from comment #12)
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.
Well over 60,000? When I have multi-arch enabled it lists over 120,000 just as quickly. And just logged in to my Sid VM, Aptitude with 63,000 packages uses exactly 1.6s CPU time to start and load everything. But with all this this is *not* the issue.
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.
Frankly, I don't care *how* it is implemented. If you use widgets, it's fine. I don't care. But it shouldn't make the window non-interactive. That's the problem from where I sit, as a user, the interface is stuck. I didn't look what is actually happening. Why the algorithm that updates a list doesn't scale. Also, sorting is not the problem. I can resort the list in Yast without issues.
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.
No, the ncurses version has a different problem. And Aptitute ncurses version doesn't have that problem with more packages. Again, I didn't look what is actually happening, but from user standpoint, it's not good. But that's a *different* problem.
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?
That's a pointless discussion. Because you are just kicking the can down the road until some group will blow up with 50,000 packages. That may just happen. ;)
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.
Anyway, my point is, 1. opening window with all packages takes time, NO PROBLEM 2. scrolling around with all packages, fast, NO PROBLEM 3. changing install state of any package, UI stuck, **PROBLEM** So, not actually looking at the code (yet), by why is this happening? Why is the UI stuck when only few elements should be updated and one redrawn? Is this a Qt problem or Yast problem? -- You are receiving this mail because: You are on the CC list for the bug.