Comparing KFileItems

[David Faure]

On Thursday 18 October 2012 13:54:09 Frank Reininghaus wrote:
> Obviously, KFileItems are only considered equal if their d pointers
> are the same.

Yes, i.e. created from the same place.

But I agree, let's compare URLs too, since they are "unique identifiers" for 
resources.

> There is a Dolphin bug where this plays a role and leads to constant
> high CPU usage:
> 
> https://bugs.kde.org/show_bug.cgi?id=304986

Tricky one, well done with the investigation!

> There are ways to fix or work around this problem inside Dolphin, but
> I'm wondering if it makes sense to change the way KFileItems are
> compared. If two items do not have the same d pointers, one could
> check if their URLs are equal and consider them equal in that case.
> Or, if that is not considered suffient for equality, do what
> KFileItem::cmp(const KFileItem&) does.

I don't think we want to call a full cmp().

If you have two KFileItems referring to the same file, but one KFileItem has 
more details than the other (e.g. because it comes from KIO while the other 
one was created from a URL only), then cmp() will say false, but they are 
still about the same item.

In other words:
* operator== is for QSet/QHash, should return true "if this is about the same 
item".
* cmp() is full comparison of all details, useful in KDirLister after an 
update (re-listing a directory), to find out if any detail has changed.

I am very much against operator== calling a full cmp(), it's slow and doesn't 
make sense, it will lead to new bugs when using KFileItem in QSet/QHash and 
any detail is updated in a KFileItem copy.

But I agree with comparing URLs.

A KFileItem is basically "a URL with extra info associated". I suppose we use 
KFileItem and not QUrl as the key in KFileItemModelRolesUpdater simply in 
order to have this extra info available? But the QUrl is really the key, the 
rest is associated data.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5