Comment # 10 on bug 1074138 from Stefan Hundhammer

(In reply to Adam Majer from comment #8)
> In "modern" UI, like if you look at Thunderbird or Firefox or Chrome, when
> you want to find something, you have search-on-type feature. A snappy UI
> allows for something like that to actually be implemented.

We have a search filter view. Just use that one if you want to search
something. We are not trying to recreate Thunderbird here (which has this kind
of search box right above the list), and both Firefox and Chrome don't deal
with lists at all; they have a generic "Find on this page" search function
which is something completely different.

> Listing all packages is useful, especially if I want to remove things I
> don't use and I don't know in which category things exist. In my case, it
> would be going down the list of all installed packages and seeing if I can
> uninstall things I don't use anymore.

Just use the "Installation Summary" filter view where you can select packages
by status - e.g. "keep" in this example. 

Or use the "Repositories" filter view and select "@System".

Both will give you a considerably shorter list that will not consume as many
resources and slow down performance so drastically. I see no noticable delay
when I do that with my 4399 installed packages.

The only (easy) way to get all packages from all repositories is to go to the
"RPM Groups" filter view and then select "ZZZ All".

Guess why it's on the bottom of that tree: Because it is expected to slow down
performance.

As I wrote, I repeatedly defended that feature against requests to remove it
because albeit it does have a cost in terms of performance and resource
consumption, it is useful to some people in some cases. If this is now used
against us, I strongly vote for removing it.

Rewriting that entire part of the YQPackageManager because of that is just
insane; and that's what this comes down to. 

As I wrote not so long ago in a thread on [research] that model-view part of
the Qt item widgets is a royal PITA, it is poorly documented, it is very hard
to test, it is hard to maintain. And for what? For a single-digit number of
users who use the application the wrong way?

Just use it the way it was meant to be used and be happy.

See also 
 
https://mailman.suse.de/mlarch/SuSE/research/2017/research.2017.03/msg00035.html


> Re: [Research] Qt: How to hook into destruction of a widget?
> To: research@suse.de
> Subject: Re: [Research] Qt: How to hook into destruction of a widget?
> From: Stefan Hundhammer <shundhammer@suse.de>
> Date: Tue, 7 Mar 2017 11:47:12 +0100
> In-reply-to: <c37738d9-2c8c-919b-47d3-df70946edf4a@suse.de>
> List-archive: <https://mailman.suse.de/mailman/private/research/>
> 
> 
> 
> On 07.03.2017 11:23, Adam Majer wrote:
> 
> > I don't mean to be too picky here, just want to point out there are
> > better ways of doing these things. QListView and relevant data model
> > classes are **much** superior at this than using old-style
> > QListWidget.  Model/View separation has its many advantages.
> > 
> After having gone through this with QDirStat and after having given 7
> or 8 week-long Qt training courses each covering (almost) all aspects
> of Qt, I can only say:
> 
> No. Not only no, but HELL, NO.
> 
> Qt's model/view classes are made by theoretical people in their ivory
> tower for other theoretical people in their other ivory tower. They
> are a royal PITA, the documentation is (unlike all other Qt
> documentation) piss-poor, there are aspects of it that are completely
> (!) undocumented (talk about QPersistentModelIndex), and they are
> using private methods in their own derived classes all the time (which
> should have given them some hints that their own API is insufficient
> and too limiting), and it is completely undebuggable.
> 
> After working almost exclusively with and on Qt (we maintained the Qt
> libs for the Nokia Harmattan/MeegoTouch project on the N9 phone) I
> struggled with this stuff for QDirStat and just barely got it to work
> during the 12/2015 hackweek.
> 
> As a matter of fact, I had already officially given up QDirStat
> because of that just 2 hours prior to the 2015 SUSE Christmas party
> (already written a really interesting rant for its home page) because
> this crap just did random things with no means whatsoever to debug
> anything.
> 
> I didn't go to the party because I was so pissed off at that crap: I
> didn't want to spoil everybody else's party because of that. Only some
> hours later I got yet another idea how to track the problem down, and
> then I found what I had done wrong - without ANY of those Qt classes
> giving any hint whatsoever what they didn't like. I was just lucky.
> 
> Qt is otherwise a well-designed and great framework. But that
> model-view stuff is just a fucking piece of shit; I can't put it into
> other words.
> 
> So, for everybody just starting with Qt: By all means, forget that
> model-view stuff until you are comfortable with the easy way of doing
> things.
> 
> And when you start doing model-view stuff, try the easy
> one-dimensional list first, then work your way up to the
> two-dimensional table. Should you consider using the tree model,
> consider psychotherapy first to check what is wrong with you and what
> exactly you are trying to prove. Then talk to somebody who has done
> this before and ask him if he would really do it again.
> 
> For the purposes of average programming, use the QListWidget /
> QListWidgetItem classes rather than the QListView / QAbstractItemModel
> etc. classes. It's just too painful to use the latter with little (if
> any) gain whatsoever.
> 
> 
> Kind regards
> --
> Stefan Hundhammer  <shundhammer@suse.de>
> YaST Developer / QDirStat Author
> Qt since 1998 / Certified Qt Developer / Qt Trainer
> 
> SUSE Linux GmbH
> GF: Felix Imend�rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N�rnberg)
> Maxfeldstr. 5, 90409 N�rnberg, Germany