KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions

Mark markg85 at gmail.com
Mon Feb 4 22:28:36 UTC 2013


On Wed, Jan 23, 2013 at 4:05 PM, Mark <markg85 at gmail.com> wrote:
> On Wed, Jan 23, 2013 at 3:35 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
>> On Monday, January 21, 2013 21:09:59 you wrote:
>>> - RMB context menu
>>> - App wide shortcuts
>>> - Clipboard integration..
>>
>> these are all being worked on.
>
> Gladly :) But as said.. Qt 5.2 or even 5.3 material. Certainly not 5.1.
>>
>>> In my DirModel i took a good close look at the current DisplayRole
>>> stuff. It was a blocking call that could potentially slow the
>>> interface down. Not anymore! I added a new role called: "MimeOrThumb"
>>> which will display either a mime image or a thumbnail image:
>>> http://gitorious.org/porpoise/master/blobs/master/dirmodel.cpp#line204
>>> That alone won't make it non blocking.
>>
>> instead of a new role, could this simply be used for DisplayRole?
>
> Yes and no. If the DisplayRole is intended to be a
> image/pixmap/graphic then no. If it's also allowed to be a textual
> value then it is certainly possible. I'll follow your judgement here.
> Can i interpret the DisplayRole as textual value?
>>
>>> I needed the power of the
>>> Image{} element since that can be set to handle images asynchronous
>>> http://qt-project.org/doc/qt-4.8/qml-image.html#asynchronous-prop thus
>>> non blocking. In order to get that done, i added 2 image handlers,
>>> "image://mime/<icon>" and "image://thumb/<full pretty url> which you
>>> can find here:
>>> http://gitorious.org/porpoise/master/blobs/master/mimeimageprovider.h
>>
>> creative approach; it also reminds me how ugly the API for
>> QDeclarativeImageProvider is. btw, while you check the size var before using
>> it the first time, you don't do so the second time. a possible crash lurks :)
>> and if both size and requestedSize are passed in with valid values, size will
>> probably have the wrong value set. (256x256 rather than the actual
>> requestedSize that is returned) personally, i'd probably just write it like
>> this:
>>
>> const QSize s = requestedSize.isEmpty() ? QSize(256, 256) : requestedSize;
>> if (size) {
>>         *size = s;
>> }
>> return icon.pixmap(s);
>>
>> shorter, no crashes, guarantees size always gets the right value if a ptr is
>> passed in. :)
>
> Thanks, will certainly do that.
> Yeah, i kinda dislike the image://thumb/<url> and image://mime/<name>
> structure but it's the only way we have right now. It seems to work
> nicely...
>>
>>> (mime) and here
>>> http://gitorious.org/porpoise/master/blobs/master/thumbimageprovider.h
>>> (thumb). On top of that i added a KImageCache (or actually modified
>>> where it's being called) since i want to have a single point for the
>>> KImageCache i made it available through my static class:
>>> http://gitorious.org/porpoise/master/blobs/master/util.h#line35. That
>>> part won't be usable in a generic KDirModel with threading.
>>
>> assuming this one cache is used for multiple things by the application, and
>> not just the file listing model for thumbnails, a mutex around it would
>> probably be enough. it should also probably live outside the UI thread ...
>
> Nice one! But how can i do that? Put it in a thread or..?
>>
>> btw, is there any chance that you might move this to git.kde.org in future?
>
> Also yes and no. I'm using qmake now and "you guys" don't really like
> that. I'm not planning on porting it to cmake at this moment, but it
> certainly has to be done. As soon as that's done then i will put it on
> git.kde.org.
>>
>> --
>> Aaron J. Seigo
>> _______________________________________________
>> Kde-frameworks-devel mailing list
>> Kde-frameworks-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>>

I really really really dislike KDirModel and friends (KDirLister,
KFileItem). Just look at this image to see why.
http://ompldr.org/vaGNxbg

The good news? My current version is already using 100MB less.
The bad news? It's still using ~600MB

Note: this is for "only" having a model with 500.000 files in it! No
view at all. The code looks a bit like this:
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    QString url("/home/mark/500k_files/");

    KDirLister lister;
    lister.openUrl(url);

    KDirModel model;
    model.setDirLister(&lister);

    return a.exec();
}

The best news: i'm not done yet :) Mark my words, this one (KDirModel
and friends) is going to be one of KDE's most efficient classes when
i'm done. (most likely due to David Faure and me both attending the
KDEPIM meeting so that will certainly help to optimize the death out
of this class and let it use 1/10th of the memory it's using now)


More information about the Kde-frameworks-devel mailing list