Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tue, Feb 5, 2013 at 9:01 AM, Mark mark...@gmail.com wrote: On Tue, Feb 5, 2013 at 8:03 AM, Frank Reininghaus frank7...@googlemail.com wrote: Hi Mark, 2013/2/4 Mark: I really really really dislike KDirModel and friends (KDirLister, KFileItem). before you get even more emotional in your next reply to this thread, please consider reading http://www.kde.org/code-of-conduct/ I sort of got used to reading disrespectful messages with little useful content from a small minority of our user base, but I feel at least mildly offended when I read such statements on a developer-only mailing list. Not only because the classes you mention have been serving us well for quite some time and David does an awesome job maintaining them (he fixes a bug in no time at all as soon as I throw a half-ready unit test at him), but also because they contain some contributions from myself. Yes, it's mostly unit tests and one-line patches, but in some cases, I needed a few hours of backtrace and code reading before I could figure out what's going wrong [1]. Thanks for your understanding and best regards, Frank [1] https://bugs.kde.org/show_bug.cgi?id=196695 Hi Frank, the really really really dislike part was meant to be taken seriously. Specially not after adding a screenshot with it's memory usage. I like diving into those classes and try to figure out more optimal ways of doing things, i certainly don't hate them nor disrespect the authors of them. The thing i'm puzzling most with right now is how i can optimize UDSEntry. Internally it's a hash and that very visible in profiling. Also in KFileItem one part that i find a little strange is this line: http://quickgit.kde.org/?p=kdelibs.gita=blobh=6667a90ee9e1d57488bb7e085167658f2fb9f172hb=533b48c610319f3ad67e6f5f0cbb65028b009b8ff=kio%2Fkio%2Fkfileitem.cpp (line 290). That line is causing a chain of performance penalties. Which is very odd because i'm testing this benchmark with 500.000 files, not directories. It should not even end up in that if. Or am i reading massif wrong..? Massif shows me that line for KUrl data consumption.. One of the highest memory consumptions. _ typo.. part was meant to be taken should be part was't meant to be taken Sorry for that. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tuesday 05 February 2013 09:01:21 Mark wrote: The thing i'm puzzling most with right now is how i can optimize UDSEntry. Internally it's a hash and that very visible in profiling. Also in KFileItem one part that i find a little strange is this line: http://quickgit.kde.org/?p=kdelibs.gita=blobh=6667a90ee9e1d57488bb7e085167 658f2fb9f172hb=533b48c610319f3ad67e6f5f0cbb65028b009b8ff=kio%2Fkio%2Fkfile item.cpp (line 290). That line is causing a chain of performance penalties. Which is very odd because i'm testing this benchmark with 500.000 files, not directories. It should not even end up in that if. You're reading the if() wrong. When used via KDirLister, KFileItem is constructed with a base URL and a UDSEntry. The base URL is the url of the directory (so urlIsDirectory is true) and the UDSEntry contains the filename (from the kioslave). So m_url.addPath(m_strName) is done, in order to construct the full URL to the file. The thing is, KDirListerCache keeps all KFileItems in cache, for faster directory browsing (of already-visited dirs). So if you want to reduce memory usage, implement a LRU mechanism in KDirListerCache, to throw out the oldest unused dirs. Would help in real life -- not really in your testcase though (one huge directory). Or am i reading massif wrong..? Massif shows me that line for KUrl data consumption.. One of the highest memory consumptions. Well, the kfileitems are kept around, and each kfileitem has a KUrl in it, which is kept too. I'm surprised that this would be the main use of memory though. Well, it's the biggest field in KFileItem, indeed. We could of course construct this KUrl on demand (so that the directory part of it is shared amongst all KFileItems, via QString's implicit sharing)... This would shift the balance towards more CPU, less memory, so one would have to check the performance impact of such a change. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by BlueSystems and KDAB to work on KDE Frameworks ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tue, Feb 5, 2013 at 10:19 AM, David Faure faure+bluesyst...@kde.org wrote: On Tuesday 05 February 2013 09:01:21 Mark wrote: The thing i'm puzzling most with right now is how i can optimize UDSEntry. Internally it's a hash and that very visible in profiling. Also in KFileItem one part that i find a little strange is this line: http://quickgit.kde.org/?p=kdelibs.gita=blobh=6667a90ee9e1d57488bb7e085167 658f2fb9f172hb=533b48c610319f3ad67e6f5f0cbb65028b009b8ff=kio%2Fkio%2Fkfile item.cpp (line 290). That line is causing a chain of performance penalties. Which is very odd because i'm testing this benchmark with 500.000 files, not directories. It should not even end up in that if. You're reading the if() wrong. When used via KDirLister, KFileItem is constructed with a base URL and a UDSEntry. The base URL is the url of the directory (so urlIsDirectory is true) and the UDSEntry contains the filename (from the kioslave). So m_url.addPath(m_strName) is done, in order to construct the full URL to the file. Ahh oke. It's not that obvious from the code. Thank you for clarifying that one. The thing is, KDirListerCache keeps all KFileItems in cache, for faster directory browsing (of already-visited dirs). So if you want to reduce memory usage, implement a LRU mechanism in KDirListerCache, to throw out the oldest unused dirs. Would help in real life -- not really in your testcase though (one huge directory). My intention is to make it fast enough to not even need a cache. Though i'm guessing that goal won't be reached since caching will still be useful for slower media. Or am i reading massif wrong..? Massif shows me that line for KUrl data consumption.. One of the highest memory consumptions. Well, the kfileitems are kept around, and each kfileitem has a KUrl in it, which is kept too. I'm surprised that this would be the main use of memory though. Well, it's the biggest field in KFileItem, indeed. We could of course construct this KUrl on demand (so that the directory part of it is shared amongst all KFileItems, via QString's implicit sharing)... This would shift the balance towards more CPU, less memory, so one would have to check the performance impact of such a change. Just wondering - since this will likely be KF5 material when patched - will this be any better with QUrl in Qt5? Or is QUrl just as heavy as KUrl? Also, lets discuss the memory usage a bit since that really shocks me. I'm having a folder with 500.000 files (generated). All 0 bytes. The filename is like this: a00.txt - a50.txt with the path: /home/mark/massive_files/ Now if we do a very rough calculation that means one complete full url looks like this: file:///home/mark/a00.txt That line is 29 characters thus lets say 29 bytes as well. Lets say we need a bit more then that for bookkeeping in QString, perhaps some other unexpected stuff so lets make it 48 bytes (just to be generous) If we multiple that by 500.000 we get: 48 * 500.000 = 2400 bytes (22.8 MB) Now lets be very generous and say that we need 5x the data to store all other fields and bookkeeping. 22.8 * 5 = ~115MB (rounded) This is uncompressed and seems very generous in terms of space. That would be the memory usage i would expect for an unoptimized KDirModel and friends. But as you can see from the screenshot, it's using a lot more memory then this. What i'd like to know is if my logic from above is what could (and should) be expected or am i missing something that is eating up a lot more memory? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tue, Feb 5, 2013 at 11:47 AM, David Faure faure+bluesyst...@kde.org wrote: On Tuesday 05 February 2013 11:05:35 Mark wrote: On Tue, Feb 5, 2013 at 10:19 AM, David Faure faure+bluesyst...@kde.org wrote: On Tuesday 05 February 2013 09:01:21 Mark wrote: The thing i'm puzzling most with right now is how i can optimize UDSEntry. Internally it's a hash and that very visible in profiling. Also in KFileItem one part that i find a little strange is this line: http://quickgit.kde.org/?p=kdelibs.gita=blobh=6667a90ee9e1d57488bb7e085 167 658f2fb9f172hb=533b48c610319f3ad67e6f5f0cbb65028b009b8ff=kio%2Fkio%2Fk file item.cpp (line 290). That line is causing a chain of performance penalties. Which is very odd because i'm testing this benchmark with 500.000 files, not directories. It should not even end up in that if. You're reading the if() wrong. When used via KDirLister, KFileItem is constructed with a base URL and a UDSEntry. The base URL is the url of the directory (so urlIsDirectory is true) and the UDSEntry contains the filename (from the kioslave). So m_url.addPath(m_strName) is done, in order to construct the full URL to the file. Ahh oke. It's not that obvious from the code. Thank you for clarifying that one. (It's documented in the API docs for the KFileItem constructor) The thing is, KDirListerCache keeps all KFileItems in cache, for faster directory browsing (of already-visited dirs). So if you want to reduce memory usage, implement a LRU mechanism in KDirListerCache, to throw out the oldest unused dirs. Would help in real life -- not really in your testcase though (one huge directory). My intention is to make it fast enough to not even need a cache. Though i'm guessing that goal won't be reached since caching will still be useful for slower media. Yeah, for FTP and such we'll always want a cache. For local files, well, surely a cache will always be faster than starting a kioslave, listing a directory, transferring that over a socket, and decoding that. I already find the file dialog a bit slow to show up with a dir listing. Let's limit its memory usage, but let's not get rid of the cache altogether. Well, the kfileitems are kept around, and each kfileitem has a KUrl in it, which is kept too. I'm surprised that this would be the main use of memory though. Well, it's the biggest field in KFileItem, indeed. We could of course construct this KUrl on demand (so that the directory part of it is shared amongst all KFileItems, via QString's implicit sharing)... This would shift the balance towards more CPU, less memory, so one would have to check the performance impact of such a change. Just wondering - since this will likely be KF5 material when patched - will this be any better with QUrl in Qt5? Or is QUrl just as heavy as KUrl? Good point: QUrl in Qt5 can be twice as small, because Qt4 kept both the encoded and the decoded versions of the fields. I say can, because I suppose it filled that on demand, so I don't know if we were actually filling both variants of every field. More details below, in fact. Also, lets discuss the memory usage a bit since that really shocks me. I'm having a folder with 500.000 files (generated). All 0 bytes. The filename is like this: a00.txt - a50.txt with the path: /home/mark/massive_files/ Now if we do a very rough calculation that means one complete full url looks like this: file:///home/mark/a00.txt That line is 29 characters thus lets say 29 bytes as well. That would be in a char*. But now think QString, every characher is a QChar, i.e. 2 bytes. Lets say we need a bit more then that for bookkeeping in QString, perhaps some other unexpected stuff so lets make it 48 bytes (just to be generous) QUrlPrivate looks rather like this, in Qt4. I added comments with expected memory usage (in bytes, on a 64bit machine) for each field. QAtomicInt ref; // 4 QString scheme; // file - 8 + 8 [d pointer] + 32 [QString::Data] QString userName; // null - 8 [d pointer] QString password; // null - 8 QString host; // null - 8 QString path; // file:///home/mark/a.txt - 58 + 8 + 32 QByteArray query; // null - 8 QString fragment; // null - 8 QByteArray encodedOriginal; // hopefully null - 8, gone in Qt5 QByteArray encodedUserName; // hopefully null - 8, gone in Qt5 QByteArray encodedPassword; // hopefully null - 8, gone in Qt5 QByteArray encodedPath; // hopefully null - 8, gone in Qt5 QByteArray encodedFragment; // hopefully null - 8, gone in Qt5 int port; // 4 QUrl::ParsingMode parsingMode; // 4, gone in Qt5 bool hasQuery; // 1 bool hasFragment; // 1 bool isValid; // 1 bool isHostValid; // 1 char valueDelimiter; // 1, gone in Qt5 [moved to QUrlQuery] char pairDelimiter; // 1, gone in Qt5 [moved to QUrlQuery] int stateFlags; // 4, gone in Qt5 QMutex mutex;
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
Hi Mark, 2013/2/4 Mark: I really really really dislike KDirModel and friends (KDirLister, KFileItem). before you get even more emotional in your next reply to this thread, please consider reading http://www.kde.org/code-of-conduct/ I sort of got used to reading disrespectful messages with little useful content from a small minority of our user base, but I feel at least mildly offended when I read such statements on a developer-only mailing list. Not only because the classes you mention have been serving us well for quite some time and David does an awesome job maintaining them (he fixes a bug in no time at all as soon as I throw a half-ready unit test at him), but also because they contain some contributions from myself. Yes, it's mostly unit tests and one-line patches, but in some cases, I needed a few hours of backtrace and code reading before I could figure out what's going wrong [1]. Thanks for your understanding and best regards, Frank [1] https://bugs.kde.org/show_bug.cgi?id=196695 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Monday, January 21, 2013 21:09:59 you wrote:
- RMB context menu
- App wide shortcuts
- Clipboard integration..
these are all being worked on.
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?
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. :)
(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 ...
btw, is there any chance that you might move this to git.kde.org in future?
--
Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Wed, Jan 23, 2013 at 3:35 PM, Aaron J. Seigo ase...@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@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tuesday, January 15, 2013 10:40:58 Frank Reininghaus wrote: Right, but considering that Dolphin doesn't even use KDirModel any more, going the QAbstractItemView way would feel like throwing away most of what happened in Dolphin in the last 2 years. dolphin still uses QAbstractItemModels, no? that's all that matters; whether it uses KDirModel or KFileItemModle or SomeOtherModel is a detail. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
Hi, 2013/1/21 Aaron J. Seigo: On Tuesday, January 15, 2013 10:40:58 Frank Reininghaus wrote: Right, but considering that Dolphin doesn't even use KDirModel any more, going the QAbstractItemView way would feel like throwing away most of what happened in Dolphin in the last 2 years. dolphin still uses QAbstractItemModels, no? that's all that matters; whether it uses KDirModel or KFileItemModle or SomeOtherModel is a detail. No, it doesn't, see http://ppenz.blogspot.de/2011/08/introducing-dolphin-20.html Regards, Frank ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Monday, January 21, 2013 17:53:48 Frank Reininghaus wrote: http://ppenz.blogspot.de/2011/08/introducing-dolphin-20.html Ah, that's right .. it uses ItemViewsNG. of which the last commits seem to be in 2010, and QGraphicsView is not receiving much attention now either :/ i suppose as long as ItemViewsNG+QGraphicsView doesn't bitrot too much and performance remains acceptable, then there's no forced changes required towards QML. maybe that will hold for a number of years yet, even. when Qt Desktop Components become available for use and testing (supposed to come with 5.1), that might be another option as it comes with a few things a dolphin-type application will need/want: visual integration with the host desktop (e.g. QStyle bridging) and various item views that QML currently lacks ... but that will still require a QAIM based model for directory listings that is performant. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Mon, Jan 21, 2013 at 8:01 PM, Aaron J. Seigo ase...@kde.org wrote: On Monday, January 21, 2013 17:53:48 Frank Reininghaus wrote: http://ppenz.blogspot.de/2011/08/introducing-dolphin-20.html Ah, that's right .. it uses ItemViewsNG. of which the last commits seem to be in 2010, and QGraphicsView is not receiving much attention now either :/ i suppose as long as ItemViewsNG+QGraphicsView doesn't bitrot too much and performance remains acceptable, then there's no forced changes required towards QML. maybe that will hold for a number of years yet, even. when Qt Desktop Components become available for use and testing (supposed to come with 5.1), that might be another option as it comes with a few things a dolphin-type application will need/want: visual integration with the host desktop (e.g. QStyle bridging) and various item views that QML currently lacks ... but that will still require a QAIM based model for directory listings that is performant. -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel With all respect, QML 2 is miles away from being usable as a desktop application! I know since i'm trying very very hard to get there hence my recent blog posts to make the clipboard available in QML and the application wide shortcuts. One last thing that isn't there yet is a menu for the right mouse button. And just implementing it on the application scene won't work since the RMB window has to be able to go outside the area of the application. A RMB probably has to be a top level widget. I'm guessing Qt5 won't be ready for full fledged desktop application - as you would expect a desktop application - before Qt 5.2 or perhaps even 5.3. Aaron, do you have any news regarding that DirModel of yours and Marco that is threaded? I would be very interested in using that one + it saves me quite some time to make it myself :) Cheers, Mark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
Hi, 2013/1/21 Aaron J. Seigo ase...@kde.org: On Monday, January 21, 2013 17:53:48 Frank Reininghaus wrote: http://ppenz.blogspot.de/2011/08/introducing-dolphin-20.html Ah, that's right .. it uses ItemViewsNG. of which the last commits seem to be in 2010, and QGraphicsView is not receiving much attention now either :/ It doesn't use the 2010 version of ItemViews-NG. To quote from Peter's blog: So the new view-engine for Dolphin 2.0 is build on a (very) modified subset of Itemviews-NG. As long as we work on it, it will not bit rot. (The situation might be different for QGraphics* though). Regards, Frank ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Monday, January 21, 2013 20:18:03 you wrote: I'm guessing Qt5 won't be ready for full fledged desktop application - maybe you wouldn't say that if you'd seen the QML Desktop Components demo applications :) jump to around minute 57 of http://www.youtube.com/watch?v=Y1pqL5bXe0A native menus are currently being worked on, and this is targetted for inclusion in Qt 5.1 Aaron, do you have any news regarding that DirModel of yours and Marco that is threaded? oh, we don't have such a thing right now. we need to write one. what we threaded was the nepomuk model, which is used in Active for most (though not all) file listings. it's one of the reasons i'm watching this thread with such interest as an improved KDirModel that doesn't disturb the gui thread even while loading would be very nice. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tuesday 15 January 2013 17:14:52 Mark wrote: We're talking about application level now. In other terms: off topic ;) Not completely. It's good to decide on an overall direction for a given issue, before determining which layer should do what. If we decide that it's ok to compute things incrementally, or to sort only when all the data is in, because the application will hide the view until the right time, then we know it won't create trouble, so it's a good solution overall. Otherwise another solution must be found in the model to prevent things jumping around visually. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tue, Jan 15, 2013 at 11:25 PM, David Faure fa...@kde.org wrote: On Tuesday 15 January 2013 17:14:52 Mark wrote: We're talking about application level now. In other terms: off topic ;) Not completely. It's good to decide on an overall direction for a given issue, before determining which layer should do what. If we decide that it's ok to compute things incrementally, or to sort only when all the data is in, because the application will hide the view until the right time, then we know it won't create trouble, so it's a good solution overall. Otherwise another solution must be found in the model to prevent things jumping around visually. Good point :) I'd say the programmatic default is to show data asap even if that means jumping views. But perhaps there should be a flag function in KDirModel to change that behavior. For example the following: --Enum values /** Incrementing updates will update the model as soon as data arrives. This might case the view to jump when new data fed in the model */ - UpdateFlags::IncrementingUpdates /** Full updates will only update the actual model data once the finished signal is received from the internal KDirLister. The view will only change when all data is in */ - UpdateFlags::FullUpdates Then a KDirModel function for it like so: KDirModel::flags(UpdateFlags flags); I think that is reasonable, right? Doing this will give the application full control whether to use batching (UpdateFlags::IncrementingUpdates) or nor (UpdateFlags::FullUpdates). The current behavior is actually batching, but batching _was_ done very poorly and using application don't really seem to make use of it anyway - as in the listen for the finished signal thus rendering batching useless. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
Le mercredi 9 janvier 2013 16:42:25 Mark a écrit : Dolphin happens to be a big user here, but i'm really not talking about dolphin specifically. The structures behind it are my target :) Filtering will indeed be done afterwards, but you have to think about it. What would be better? 1. A fast usable list that resorts itself when all data is in. 2. A - still fast - list but not usable till all data is in. 3. A really slow and actually unusable list even when all data is in and sorted. My aim with this thread it to get at number 1. Dolphin right now is at number 3. Do know that i'm talking about massive folders 100.000+ items. I am not an expert on the lower-level details of KDirLister and KFileItem (even if they are used a lot in Gwenview), but from a user-experience point of view a list which resorts itself is going to be painful to use: it is very frustrating to start moving the mouse to click on an item, but by the time you reach the position you aimed for, the item has moved somewhere else. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tue, Jan 15, 2013 at 3:42 PM, Aurélien Gâteau agat...@kde.org wrote: Le mercredi 9 janvier 2013 16:42:25 Mark a écrit : Dolphin happens to be a big user here, but i'm really not talking about dolphin specifically. The structures behind it are my target :) Filtering will indeed be done afterwards, but you have to think about it. What would be better? 1. A fast usable list that resorts itself when all data is in. 2. A - still fast - list but not usable till all data is in. 3. A really slow and actually unusable list even when all data is in and sorted. My aim with this thread it to get at number 1. Dolphin right now is at number 3. Do know that i'm talking about massive folders 100.000+ items. I am not an expert on the lower-level details of KDirLister and KFileItem (even if they are used a lot in Gwenview), but from a user-experience point of view a list which resorts itself is going to be painful to use: it is very frustrating to start moving the mouse to click on an item, but by the time you reach the position you aimed for, the item has moved somewhere else. Aurélien Well, sorting is very fast now (in my test environment) and fast enough for regular data to be sorted before you see the data. That's not an issue. The issue arises when data arrives in batches. For example: - Batch 1 comes in - - Sort batch one - - Present it to the user - Batch 2 comes in - - Sort batch 1 + 2 - - Present the new data (both batches) to the user If there is just one batch then there is no issue at all. If there is more then one then you will eventually see a change in your model.. OR you don't show any data till everything is in and show a complete list. That's the current approach in dolphin but also leads to a white window for a few seconds (depending on the number of files) My preference would be to show data asap even if that means that the list will change under your mouse. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
Le mardi 15 janvier 2013 16:04:39 Mark a écrit : Well, sorting is very fast now (in my test environment) and fast enough for regular data to be sorted before you see the data. That's not an issue. The issue arises when data arrives in batches. For example: - Batch 1 comes in - - Sort batch one - - Present it to the user - Batch 2 comes in - - Sort batch 1 + 2 - - Present the new data (both batches) to the user If there is just one batch then there is no issue at all. If there is more then one then you will eventually see a change in your model.. OR you don't show any data till everything is in and show a complete list. That's the current approach in dolphin but also leads to a white window for a few seconds (depending on the number of files) My preference would be to show data asap even if that means that the list will change under your mouse. Showing a white window is bad indeed, but this can be mitigated with an overlayed spinner to show there is activity going on. Moving file lists around can potentially have disastrous consequences: think about clicking an item and then pressing the Delete key... Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Tue, Jan 15, 2013 at 5:06 PM, Aurélien Gâteau agat...@kde.org wrote: Le mardi 15 janvier 2013 16:04:39 Mark a écrit : Well, sorting is very fast now (in my test environment) and fast enough for regular data to be sorted before you see the data. That's not an issue. The issue arises when data arrives in batches. For example: - Batch 1 comes in - - Sort batch one - - Present it to the user - Batch 2 comes in - - Sort batch 1 + 2 - - Present the new data (both batches) to the user If there is just one batch then there is no issue at all. If there is more then one then you will eventually see a change in your model.. OR you don't show any data till everything is in and show a complete list. That's the current approach in dolphin but also leads to a white window for a few seconds (depending on the number of files) My preference would be to show data asap even if that means that the list will change under your mouse. Showing a white window is bad indeed, but this can be mitigated with an overlayed spinner to show there is activity going on. Moving file lists around can potentially have disastrous consequences: think about clicking an item and then pressing the Delete key... Aurélien We're talking about application level now. In other terms: off topic ;) The KDirModel as i proposed it will just have that functionality, but it won't do any sorting by default (just like it's working now) so for apps using KDirModel nothing will change. It's more of a massive internal refactoring while maintaining (most) of the external API. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Thu, Jan 10, 2013 at 11:54 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, January 10, 2013 19:37:39 you wrote: Is there another dirmodel fork somewhere that does that? Link please :) well, what we ought to do is do a threaded version and then put it somewhere we can all share it properly :) i'll discuss with Marco what he thinks and come back with a proposal. you make it sound like it's closed source..? no link to some exotic highly experimental git branch? hehe.. no, none yet ... reason i want to talk about with Marco is this will impact our devel efforts elsewhere in the plasma-mobile code, so we would need to factor any changes in there. and this really seems like the sort of thing that ought to be available in the Plasma Components in kde-runtime so that everyone can use it (and hack on it) without making copies :) so +1 from me for making KDirModel do its business in an encapsulated thread. I guess that is the way forward then. But i do wonder, if the KDirModel API stays the same but the internals change completely, is that KF5 material or can it go in 4.xx as well? imho, probably KF5 because: a) we want KF5 sooner rather than later, so efforts should focus there.[1] b) KDirModel is such a key component with a high complexity and few people who know it very well; so it needs lots of testing, and 5.0 would be a better target for that kind of development imho c) it will give us something to market about 5.0 - SO MUCH FASTER / MORE FLUID DIRECTORY LISTINGS (that's mostly, but only mostly, tongue-in-cheek) [1] as an aside: we've re-focused effort on libplasma2 in KF5. the new QML based containment stuff being worked on has been moved to libplasma2-only and i expect other such development in Plasma to continue that way. we're also expecting / planning Plasma Active 5 to be focused on moving to Qt5 + KF5. -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Just wondering a little thing about making KDirModel threaded.. How can you even do that? KDirModel inherits from QAbstractItemModel and that works just fine. If you add in threading the KDirModel doesn't inherit from QAbstractItemModel anymore.. The internal class KDirModelPrivate would inherit from QAbstractItemModel where KDirModel itself would inherit from probably QObject. ..? Or would the KDirModel need to inherit from QThread? Just something i wonder because setModel(QAbstractItemModel * model) needs a class that's subclassing QAbstractItemModel which KDirModel isn't doing in the above scenario.. I'm probably missing something obvious here. I hope someone can explain how that is supposed to be resolved? Cheers, Mark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
Hi, 2013/1/9 Mark: On Wed, Jan 9, 2013 at 2:51 PM, David Faure wrote: On Wednesday 09 January 2013 11:15:20 Mark wrote: A little more in depth questions for KDirLister and KFileItem. In my profiling KFileItem ends up high due to various reasons, but KDirLister is also a bit of a heavy resource hog due to it's default behavior of fetching all file information (thus at least 1 stat call per file) which severely slows down the dir listing process for large folders. This stat call happens in kio_file though, not in the GUI process where KDirLister lives, right? So I'm surprised that you see that when profiling... or is there a nasty stat() in KDirLister somewhere? ehm, well i'm not really monitoring stat calls. I'm monitoring the time it takes for a directory listing on 1 million files to be available in my application. I agree that we should try to behave well even if there are many files. However, if it is ensured if all algorithms involved in loading item information and view setup are O(N) or at most O(N*log(N)) (like sorting), then the remaining slowness for many files is something that the user might just have to live with IMHO. I'm not saying that everything is good as it is. If there are some operations with quadratic or worse complexity involved, then this should be looked into, of course. And I also do realise that Dolphin could benefit from making use of your listJob batching improvements (https://git.reviewboard.kde.org/r/107520/, very nice work BTW!). But making extremely intrusive changes to well-tested code which are only motivated by the (IMHO rather exotic) 1 million files use case and which would require large changes everywhere in KDE might not be such a good idea. Just my opnion, of course. Best regards, Frank P.S.: I agree that the lazy folder icon loading issue mentioned elsewhere in this thread can be disturbing sometimes and could be improved. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Thu, Jan 10, 2013 at 9:23 AM, Frank Reininghaus frank7...@googlemail.com wrote: Hi, 2013/1/9 Mark: On Wed, Jan 9, 2013 at 2:51 PM, David Faure wrote: On Wednesday 09 January 2013 11:15:20 Mark wrote: A little more in depth questions for KDirLister and KFileItem. In my profiling KFileItem ends up high due to various reasons, but KDirLister is also a bit of a heavy resource hog due to it's default behavior of fetching all file information (thus at least 1 stat call per file) which severely slows down the dir listing process for large folders. This stat call happens in kio_file though, not in the GUI process where KDirLister lives, right? So I'm surprised that you see that when profiling... or is there a nasty stat() in KDirLister somewhere? ehm, well i'm not really monitoring stat calls. I'm monitoring the time it takes for a directory listing on 1 million files to be available in my application. I agree that we should try to behave well even if there are many files. However, if it is ensured if all algorithms involved in loading item information and view setup are O(N) or at most O(N*log(N)) (like sorting), then the remaining slowness for many files is something that the user might just have to live with IMHO. I'm not saying that everything is good as it is. If there are some operations with quadratic or worse complexity involved, then this should be looked into, of course. And I also do realise that Dolphin could benefit from making use of your listJob batching improvements (https://git.reviewboard.kde.org/r/107520/, very nice work BTW!). Thank you for the compliment :) That could be a nice improvement in dolphin indeed. However, while testing that in my application (with 1 million files) i found an issue that you are very likely to have as well. While the files do show up very rapidly, the actual view is still barely usable as long as files are dripping in. This is the same in QML (ListView) as in QWidgets (QTreeView). The issue here is that the view - even though it's not showing the items - is doing all the calculations for every item added. I have no clue how to fix that issue and if it's fixed it likely has to be done upstream in Qt itself. For Dolphin that might be different since it has it's own fully implemented view so you probably have to look at it there. But making extremely intrusive changes to well-tested code which are only motivated by the (IMHO rather exotic) 1 million files use case and which would require large changes everywhere in KDE might not be such a good idea. Just my opnion, of course. Well, in my test cases my initial goal of 100.000 - 200.000 files is reached :) So then i upped my demands to 1 million. But you already notice slowdowns in dolphin with 10.000+ files, it kinda depends on your hardware as well. I know that i'm testing extremes right now :) Best regards, Frank P.S.: I agree that the lazy folder icon loading issue mentioned elsewhere in this thread can be disturbing sometimes and could be improved. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Thursday, January 10, 2013 11:30:35 Mark wrote: very rapidly, the actual view is still barely usable as long as files are dripping in. This is the same in QML (ListView) as in QWidgets The issue here is that the view - even though it's not showing the items - is doing all the calculations for every item added if so, then the QML is being done wrong in some way. the default views in QML (along with some we've written ourselves) only creates delegates for items that are shown along with +/-N pages for caching (so when you scroll you don't see things updating; the updates are happening N pages further down the scrolling) under no circumstances should the entire set of icons be laid out at any time. memory usage and CPU usage simply prohibits this, as you noted :) QML makes it really simple to just lay out what is needed (shown +/- some scroll-ahead pages); this in turn makes it easier to write the model so it is lazy loading: only load the essentials (even progressively; QML views handle this just fine) and then when requested load details. because QML binds data to properties, the async nature of this does not cause further complexity in your code: it all happens in the QML runtime. a new delegate is made for a given index (automatically based on scrol position and view size), it binds to the data for that index, the model then knows something has requested that data and goes to fetch it (whenever/however it feels :) and when it updates that data then the delegate also automatically is updated .. all without dealing with paint events and other annoyances of views with delegates written in the imperative style. this allows huge (even infinite!) size models to be written that feed views that are performant even on mobile devices ... with very little effort. in the case of dolphin, i can imagine a goal that could lead to over- calculating: wanting even spacing between all icons, which in turn means knowing how much space each and every icon will require (thumbnail? how much text? etc.) if that is the case currently, i would suggest dropping this goal and only change the spacing dimension when new icons are shown that require it. (again, easy enough with QML.) also, the model itself can process some statistics (e.g. longest name) as it loads. this can be put into a Q_PROPERTY that the QML can then access. with C++/QWidget, the annoyance with this approach is then you need to reference the C++ object with the exact type and you end up welding models and views together and .. with QML all the properties are dynamic. you can test for their existence and use them if they are there ... and this is also rather efficiently implemented. all of this is a very long-winded way of saying: if you do QML correctly and write the model accordingly, you should be able to have a stupidly fast view. (at least from the user's perspective :) i know because i've seen QML views on models with millions of entries scrolling insanely smoothly with complex and beautiful delegates. i've also helped write a couple. including doing it wrong a few times while learning :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Thu, Jan 10, 2013 at 12:20 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, January 10, 2013 11:30:35 Mark wrote: very rapidly, the actual view is still barely usable as long as files are dripping in. This is the same in QML (ListView) as in QWidgets The issue here is that the view - even though it's not showing the items - is doing all the calculations for every item added if so, then the QML is being done wrong in some way. the default views in QML (along with some we've written ourselves) only creates delegates for items that are shown along with +/-N pages for caching (so when you scroll you don't see things updating; the updates are happening N pages further down the scrolling) under no circumstances should the entire set of icons be laid out at any time. memory usage and CPU usage simply prohibits this, as you noted :) QML makes it really simple to just lay out what is needed (shown +/- some scroll-ahead pages); this in turn makes it easier to write the model so it is lazy loading: only load the essentials (even progressively; QML views handle this just fine) and then when requested load details. because QML binds data to properties, the async nature of this does not cause further complexity in your code: it all happens in the QML runtime. a new delegate is made for a given index (automatically based on scrol position and view size), it binds to the data for that index, the model then knows something has requested that data and goes to fetch it (whenever/however it feels :) and when it updates that data then the delegate also automatically is updated .. all without dealing with paint events and other annoyances of views with delegates written in the imperative style. this allows huge (even infinite!) size models to be written that feed views that are performant even on mobile devices ... with very little effort. in the case of dolphin, i can imagine a goal that could lead to over- calculating: wanting even spacing between all icons, which in turn means knowing how much space each and every icon will require (thumbnail? how much text? etc.) if that is the case currently, i would suggest dropping this goal and only change the spacing dimension when new icons are shown that require it. (again, easy enough with QML.) also, the model itself can process some statistics (e.g. longest name) as it loads. this can be put into a Q_PROPERTY that the QML can then access. with C++/QWidget, the annoyance with this approach is then you need to reference the C++ object with the exact type and you end up welding models and views together and .. with QML all the properties are dynamic. you can test for their existence and use them if they are there ... and this is also rather efficiently implemented. all of this is a very long-winded way of saying: if you do QML correctly and write the model accordingly, you should be able to have a stupidly fast view. (at least from the user's perspective :) i know because i've seen QML views on models with millions of entries scrolling insanely smoothly with complex and beautiful delegates. i've also helped write a couple. including doing it wrong a few times while learning :) -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi Aaron, I will explain my model - qml listview approach a little. This is 100% off topic though. I'm loading my massive file list (1 million) into a KDirModel subclass [1]. That class is then assigned to QML [2]. Where it's being used [3]. Now when i'm opening a massive folder [4] i do see my data in the qml part very rapidly. No issue thus far. But when i start scrolling _while_ the data is dripping in it's ... not very responsive. It works, no doubt about it but isn't fluid. As soon as the data finished loading (aka, no more data is added to the model) the list is very responsive and can easily scroll through millions of items. Am i doing something wrong? [1] http://gitorious.org/porpoise/master/blobs/master/dirmodel.h [2] http://gitorious.org/porpoise/master/blobs/master/main.cpp#line26 [3] http://gitorious.org/porpoise/master/blobs/master/qml/Porpoise/ViewContainer.qml#line27 [4] http://gitorious.org/porpoise/master/blobs/master/qml/Porpoise/main.qml#line24 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Thursday, January 10, 2013 14:12:30 you wrote: part very rapidly. No issue thus far. But when i start scrolling _while_ the data is dripping in it's ... not very responsive. after a quick look: the DirModel is doing all the data retrieval in the main thread as well as instantly on demand (no batching, e.g.). this means: * every allocation of a FileItem and all the work to populate it takes cycles away from the UI thread at the same time as the list is trying to scroll * KFileItems are created *and* populated regardless of whether they will be used or not, which means during scrolling things will get slower the more you scroll. they are also fully populated on creation. neither of these things is good. (and some of these issues have already been touched on in this thread) this probably requires changes to KDirModel such as: * put data processing into a thread; whether that means putting the whole of KDirModel into a worker thread or just having a thread pool for processing new KDirModelNodes / KFileItems .. others more familiar with the code would be able to answer that far better than i can right now :) but there should be near-zero time spent in the GUI thread for actually getting the file information * KFileItem needs to support lazy loading to avoid unecessary work when the information is not actually requested. there is even a TODO about this in KFileItemPrivate::init() in the 4.10 branch :) * methods like KDirModelPrivate::_k_slotNewItems need be faster and/or have their work moved into a thread. the number of times beginInsertRows/endInsertRows is called should also be minimized as that will innevitably create pauses in the GUI thread while it reacts to this perhaps some of this is already done or being done in the frameworks branch (haven't looked yet; apologies in advance for that) as to the DirModel class: * the image cache is done in the main thread. that means updating a database and writing to disk in the UI thread .. when the goal is 60fps or better, this is likely going to be too slow. * KIO::PreviewJobs are also in the main GUI thread. could be another cause for GUI latency. * DirModel::rebuildUrlToIndex is O(n) and called whenever there are new items * DirModel::updatePreview calls setData for each preview that it gets back. that causes dataChanged to be emitted. again, for each index. this needs to be batched up and/or DirModel should override data() itself to return Qt::DecorationRole when it has a preview. btw, DirModel::itemForIndex looks like it is leaking memory. so it seems DirModel is need of a scalibility refactor/rewrite, and KDirModel needs to be made read for use with threads in some fashion as well have its base performance improved with more lazy loading and batching of requests. (this feels earily similar to the model rewrites Marco ended up doing for Plasma Active ... threads and batching, threads and batching. the UI thread must not be disturbed! :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Thu, Jan 10, 2013 at 3:53 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, January 10, 2013 14:12:30 you wrote: part very rapidly. No issue thus far. But when i start scrolling _while_ the data is dripping in it's ... not very responsive. after a quick look: the DirModel is doing all the data retrieval in the main thread as well as instantly on demand (no batching, e.g.). this means: * every allocation of a FileItem and all the work to populate it takes cycles away from the UI thread at the same time as the list is trying to scroll * KFileItems are created *and* populated regardless of whether they will be used or not, which means during scrolling things will get slower the more you scroll. they are also fully populated on creation. neither of these things is good. (and some of these issues have already been touched on in this thread) this probably requires changes to KDirModel such as: * put data processing into a thread; whether that means putting the whole of KDirModel into a worker thread or just having a thread pool for processing new KDirModelNodes / KFileItems .. others more familiar with the code would be able to answer that far better than i can right now :) but there should be near-zero time spent in the GUI thread for actually getting the file information * KFileItem needs to support lazy loading to avoid unecessary work when the information is not actually requested. there is even a TODO about this in KFileItemPrivate::init() in the 4.10 branch :) * methods like KDirModelPrivate::_k_slotNewItems need be faster and/or have their work moved into a thread. the number of times beginInsertRows/endInsertRows is called should also be minimized as that will innevitably create pauses in the GUI thread while it reacts to this perhaps some of this is already done or being done in the frameworks branch (haven't looked yet; apologies in advance for that) as to the DirModel class: * the image cache is done in the main thread. that means updating a database and writing to disk in the UI thread .. when the goal is 60fps or better, this is likely going to be too slow. * KIO::PreviewJobs are also in the main GUI thread. could be another cause for GUI latency. * DirModel::rebuildUrlToIndex is O(n) and called whenever there are new items * DirModel::updatePreview calls setData for each preview that it gets back. that causes dataChanged to be emitted. again, for each index. this needs to be batched up and/or DirModel should override data() itself to return Qt::DecorationRole when it has a preview. Would a 300ms timer be acceptable in user experience? So if there are new thumbnails available, batch them and update the model only once every 300ms. Or is 300ms too much? btw, DirModel::itemForIndex looks like it is leaking memory. so it seems DirModel is need of a scalibility refactor/rewrite, and KDirModel needs to be made read for use with threads in some fashion as well have its base performance improved with more lazy loading and batching of requests. (this feels earily similar to the model rewrites Marco ended up doing for Plasma Active ... threads and batching, threads and batching. the UI thread must not be disturbed! :) Interesting! My DirModel is coming directly from plasma-mobile [1] which is not doing the threading you describe. Is there another dirmodel fork somewhere that does that? Link please :) -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel You just verified the need for KDirModel, KDirLister and KFileItem to be optmized for scalibility :-) My DirModel is basically a KDirModel but with some convenient parts. How much work would it be to let KDirModel run in it's separate thread? I'm guessing the public KDirModel would internally be nothing more then a signal/slot mechanism to a KDirModelPrivate class which is sent to it's own thread? Or would you say that sending KDirModel to it's own thread it too risky and should be done by the developer using KDirModel (like dolphin and my app) rather then internally in the private API? [1] http://quickgit.kde.org/?p=plasma-mobile.gita=blobh=1539ae3d6cf54f96af216593e5c7517df820a6b8hb=50664f4fae8243280f1e7362447a864b37a2039bf=components%2Fdirmodel%2Fdirmodel.cpp ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
Hi, 2013/1/10 Aaron J. Seigo: in the case of dolphin, i can imagine a goal that could lead to over- calculating: wanting even spacing between all icons, which in turn means knowing how much space each and every icon will require (thumbnail? how much text? etc.) The number of text lines required for each file name is indeed calculated in advance in order to get the 'maximum scroll offset' for the view, i.e., the total height of the view containing all items. This is used to set up the 'scroll bar value' - 'view offset' mapping. One could possibly avoid that by assuming that all non-visible items only use one line for the name, and only update that value for items which are inside (or close to) the visible area. But before considering such a thing, one would need to check if that is really a significant bottleneck. Quite a bit of code would need to be changed, and I can imagine that it's not completely trivial to get this right. if that is the case currently, i would suggest dropping this goal and only change the spacing dimension when new icons are shown that require it. (again, easy enough with QML.) Well, the hard part is probably to port Dolphin's views to QML in the first place ;-) I must admit that my QML knowledge is rather limited, but AFAIK, it does not provide any kind of tree view out of the box. Moreover, it seems to me that QML views work best with QAbstractItemModel subclasses. However, one of the main goals Peter had when rewriting the view engine was to get rid of QModelIndex, SortFilterProxyModels and things like these. And I really have the feeling that using plain ints to index items and not needing things like mapToSource() in every other function really does make things easier. Best regards, Frank ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Thu, Jan 10, 2013 at 7:24 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, January 10, 2013 16:49:15 you wrote: On Thu, Jan 10, 2013 at 3:53 PM, Aaron J. Seigo ase...@kde.org wrote: * DirModel::updatePreview calls setData for each preview that it gets back. that causes dataChanged to be emitted. again, for each index. this needs to be batched up and/or DirModel should override data() itself to return Qt::DecorationRole when it has a preview. Would a 300ms timer be acceptable in user experience? So if there are new thumbnails available, batch them and update the model only once every 300ms. Or is 300ms too much? probably too much (and probably more than is needed for the rate of file listing). but once you have that delay in there it is easy to test it, right? 100, 200, 300 .. it will really come down to average listing performance. if items come in clumps, then the update might only need to be really small (50ms or even less) to drop the # of updates by orders of magnitude. Guess i just have to experiment there. Interesting! My DirModel is coming directly from plasma-mobile [1] which is not doing the threading you describe. yes, i noticed :) unfortunately for you, that class was thrown together very quickly for the limited needs of listing directories on a mobile device. file counts tend to be rather low there, and file system browsing is not as core a function as it is on the desktop. so for Plasma Active, this was acceptable performance. for the desktop .. not even close :) Well, the class didn't have _that_ much extra stuff on top of KDirModel and i added even more so mine is quite different at the moment. Though not threaded. Is there another dirmodel fork somewhere that does that? Link please :) well, what we ought to do is do a threaded version and then put it somewhere we can all share it properly :) i'll discuss with Marco what he thinks and come back with a proposal. you make it sound like it's closed source..? no link to some exotic highly experimental git branch? You just verified the need for KDirModel, KDirLister and KFileItem to be optmized for scalibility :-) yep. How much work would it be to let KDirModel run in it's separate thread? I'm guessing the public KDirModel would internally be nothing more then a signal/slot mechanism to a KDirModelPrivate class which is sent to it's own thread? Or would you say that sending KDirModel to it's own thread it too risky and should be done by the developer using KDirModel (like dolphin and my app) rather then internally in the private API? for scalable models in Plasma Active, we've been putting the threading in the model itself exactly as you described (threaded signal/slot communication between the public API model and members in its private class) since doing this in each application is error prone. once it is done properly in the model, it then works everywhere. so +1 from me for making KDirModel do its business in an encapsulated thread. I guess that is the way forward then. But i do wonder, if the KDirModel API stays the same but the internals change completely, is that KF5 material or can it go in 4.xx as well? -- Aaron J. Seigo (remember to press reply to all ^_-) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Thursday, January 10, 2013 19:37:39 you wrote: Is there another dirmodel fork somewhere that does that? Link please :) well, what we ought to do is do a threaded version and then put it somewhere we can all share it properly :) i'll discuss with Marco what he thinks and come back with a proposal. you make it sound like it's closed source..? no link to some exotic highly experimental git branch? hehe.. no, none yet ... reason i want to talk about with Marco is this will impact our devel efforts elsewhere in the plasma-mobile code, so we would need to factor any changes in there. and this really seems like the sort of thing that ought to be available in the Plasma Components in kde-runtime so that everyone can use it (and hack on it) without making copies :) so +1 from me for making KDirModel do its business in an encapsulated thread. I guess that is the way forward then. But i do wonder, if the KDirModel API stays the same but the internals change completely, is that KF5 material or can it go in 4.xx as well? imho, probably KF5 because: a) we want KF5 sooner rather than later, so efforts should focus there.[1] b) KDirModel is such a key component with a high complexity and few people who know it very well; so it needs lots of testing, and 5.0 would be a better target for that kind of development imho c) it will give us something to market about 5.0 - SO MUCH FASTER / MORE FLUID DIRECTORY LISTINGS (that's mostly, but only mostly, tongue-in-cheek) [1] as an aside: we've re-focused effort on libplasma2 in KF5. the new QML based containment stuff being worked on has been moved to libplasma2-only and i expect other such development in Plasma to continue that way. we're also expecting / planning Plasma Active 5 to be focused on moving to Qt5 + KF5. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Wednesday 09 January 2013 11:15:20 Mark wrote: A little more in depth questions for KDirLister and KFileItem. In my profiling KFileItem ends up high due to various reasons, but KDirLister is also a bit of a heavy resource hog due to it's default behavior of fetching all file information (thus at least 1 stat call per file) which severely slows down the dir listing process for large folders. This stat call happens in kio_file though, not in the GUI process where KDirLister lives, right? So I'm surprised that you see that when profiling... or is there a nasty stat() in KDirLister somewhere? My idea is as follows here. By default fetch as little information as possible. So make KDirLister fetch the folder content using details = 0 by default. Perhaps with an additional KDirLister function (or flag) to change it's behavior to fetch all info (like it works now). The magic should happen in KFileItem. Right now that class isn't lazy loaded at all thus you get as many KFileItem instances as you have entries in the folder your listing. What i want to do here is make it lazy loading. When the class constructs it should have the immediate availability of the current UDSEntry without making anything heavy. The model can then use this class just fine. When a KFileItem is constructed it should (in the background) fetch the file to get all the details. When that's done it should notify the model of the data change which in turn makes the model update it's data. You realize that fetching the additional info means an async kio job, in the general case (non local files), right? Surely we don't want to do this in KFileItem itself (value class, no QObject, no signals), but in KDirLister itself. In fact, we don't want a KIO::stat per file, but a full-details listing for everything in one go, otherwise there will be a lot of jobs and roundtrips to kioslaves involved. More complexity in KDirLister, though, isn't something I'm looking forward to. Did you check the speed difference between details==0 and details==2? For local files it's just one stat() call per file (yes that can be a lot of calls, but I'd like proof that this actually makes a difference compared to everything else). And for other protocols there's no difference, even (with FTP you have to list the directory, which gives you full details anyway), so the two-stage approach will only make it slower. Using this approach the model can show data a lot faster (it doesn't have to wait for the file details anymore) and will automatically update it's entry when KFileITem tells it to do so.The net result for the user should be a much faster (visually) file browsing experience which should be a lot less taxing on the CPU and memory. This only works in an icon view with no details and no filtering. If you ask for details under the icons (size, etc.) it will come in delayed, and if you use a list view, the details columns will come in delayed; visually this might be ok, or arguable, don't really know. This is starting to be a topic for kfm-devel so that the dolphin developers can give their input as well... For sure it will break or complicate filtering. It's more rare so I guess it's ok if it works delayed, but it still has to be taken into account. Overall, I'm just not sure the speed gain vs complexity ratio is high enough. We already identified reading .desktop files and .directory files as something that has to be done delayed, I would very much favor doing that first, it's clearly a much bigger performance issue for network-mounted paths. Martin Koller had started some time ago, but I'm not sure what the current status is; if he doesn't have time to finish maybe you can take over that :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Wed, Jan 9, 2013 at 2:51 PM, David Faure fa...@kde.org wrote: On Wednesday 09 January 2013 11:15:20 Mark wrote: A little more in depth questions for KDirLister and KFileItem. In my profiling KFileItem ends up high due to various reasons, but KDirLister is also a bit of a heavy resource hog due to it's default behavior of fetching all file information (thus at least 1 stat call per file) which severely slows down the dir listing process for large folders. This stat call happens in kio_file though, not in the GUI process where KDirLister lives, right? So I'm surprised that you see that when profiling... or is there a nasty stat() in KDirLister somewhere? ehm, well i'm not really monitoring stat calls. I'm monitoring the time it takes for a directory listing on 1 million files to be available in my application. There i see a massive time difference when i use details = 0 (no stat) and no details provided (all details). KDirLister ends up high in the stack because it parses a massive QByteArray that comes from kio_file. I wasn't actually talking about the stat call but more about the massive data (as a result of that stat call) that gets send back. My idea is as follows here. By default fetch as little information as possible. So make KDirLister fetch the folder content using details = 0 by default. Perhaps with an additional KDirLister function (or flag) to change it's behavior to fetch all info (like it works now). The magic should happen in KFileItem. Right now that class isn't lazy loaded at all thus you get as many KFileItem instances as you have entries in the folder your listing. What i want to do here is make it lazy loading. When the class constructs it should have the immediate availability of the current UDSEntry without making anything heavy. The model can then use this class just fine. When a KFileItem is constructed it should (in the background) fetch the file to get all the details. When that's done it should notify the model of the data change which in turn makes the model update it's data. You realize that fetching the additional info means an async kio job, in the general case (non local files), right? Ah crap, didn't thought about that one.. How can that be resolved? Surely we don't want to do this in KFileItem itself (value class, no QObject, no signals), but in KDirLister itself. In fact, we don't want a KIO::stat per file, but a full-details listing for everything in one go, otherwise there will be a lot of jobs and roundtrips to kioslaves involved. More complexity in KDirLister, though, isn't something I'm looking forward to. I don't know. If the visual experience is faster because it will then obviously do lazy loading.. More on this below. Did you check the speed difference between details==0 and details==2? For local files it's just one stat() call per file (yes that can be a lot of calls, but I'd like proof that this actually makes a difference compared to everything else). And for other protocols there's no difference, even (with FTP you have to list the directory, which gives you full details anyway), so the two-stage approach will only make it slower. Didn't check that one. Using this approach the model can show data a lot faster (it doesn't have to wait for the file details anymore) and will automatically update it's entry when KFileITem tells it to do so.The net result for the user should be a much faster (visually) file browsing experience which should be a lot less taxing on the CPU and memory. This only works in an icon view with no details and no filtering. If you ask for details under the icons (size, etc.) it will come in delayed, and if you use a list view, the details columns will come in delayed; visually this might be ok, or arguable, don't really know. This is starting to be a topic for kfm-devel so that the dolphin developers can give their input as well... Dolphin happens to be a big user here, but i'm really not talking about dolphin specifically. The structures behind it are my target :) Filtering will indeed be done afterwards, but you have to think about it. What would be better? 1. A fast usable list that resorts itself when all data is in. 2. A - still fast - list but not usable till all data is in. 3. A really slow and actually unusable list even when all data is in and sorted. My aim with this thread it to get at number 1. Dolphin right now is at number 3. Do know that i'm talking about massive folders 100.000+ items. For sure it will break or complicate filtering. It's more rare so I guess it's ok if it works delayed, but it still has to be taken into account. Overall, I'm just not sure the speed gain vs complexity ratio is high enough. We already identified reading .desktop files and .directory files as something that has to be done delayed, I would very much favor doing that first, it's clearly a much bigger performance issue for network-mounted paths. Martin Koller had started
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
Le lundi 31 décembre 2012 11:43:47 David Faure a écrit : [snip] If you want to think bigger redesign, one could consider adding the necessary API to KDirModel so that direct usage of KDirLister isn't necessary anymore, i.e. encapsulating it completely. Then looking at whether all the app code can be ported away from KDirLister, to use either KDirModel or KIO::listDir (when no storage is required, just a one-time listing). A quick look at lxr.kde.org (for KDirLister) seems to indicate that this should be possible. Most cases are using a KDirModel already, and just use KDirLister to call openUrl or to enable directories only mode. On the other hand, http://lxr.kde.org/source/kde/kdeedu/kstars/kstars/ekos/capture.cpp should use KIO::listDir directly, I think. http://lxr.kde.org/source/kde/kdegraphics/gwenview/importer/documentdirfinde r.cpp too, AFAICS. (Aurélien: storing the items isn't needed, in that code, right?) Not sure what storing you are referring to: this code does not store any item, does it? Anyway this whole class is not needed anymore, I should just remove it. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Friday 28 December 2012 02:50:53 Mark wrote: Hi, -- Be sure to read all of this (long!) mail or parts won't make sense! -- -- cross posting to frameworks and KCD since it concerns both -- I'll let the k-c-d people come here if they want to participate. cases that would be oke, but if you have really massive folders then having a list of - let say - 100.000 files/folders in KFileItem objects begins to be quite taxing for the CPU. That alone isn't an issue, but the fact that you won't even see those 100.000 items in any view makes it quite wasteful to even store it. So what i want to do is store a big (much smaller in memory) UDSEntry list where KFileItem objects are lazy loaded when actually needed. That would be a lot less taxing for the CPU and memory. CPU-wise, we could do the lazy initialization inside KFileItem itself, and the result would be pretty much the same, without exposing everyone to rather internal UDSEntries. Memory-wise you're right, though, KFileItem adds quite a bunch of data. Maybe this could be changed so that it stores its data directly into the UDSEntry, even when created from a local path directly (no UDSEntry as input). Also the caching in KDirListerCache would very likely be a lot smaller when using a UDSEntryList. You'll end up adding tons of methods to UDSEntry, to make this possible, so basically you'll turn UDSEntry into KFileItem, API wise. This doesn't make sense to me, better make KFileItem slimmer internally, and keep the API. UDSEntry is the raw storage [for things that come from a kioslave], KFileItem is the API on top [plus support for things that don't come from a kioslave]. Better keep this separated (e.g. UDSEntry is enough on the slave side), and fix the memory usage of KFileItem by changing its implementation. --- KDirModelV2 API (on top of the functions that have to be re-implemented) - void setDirLister( KDirLister* dirLister ); - KDirLister* dirLister() const; - KFileItem itemForIndex( const QModelIndex index ) const; - void setAdditionalRoles(const QHashint, QByteArray roleNames) - The column names should get some defaults that can also be used in QML. This can be done in the current KDirModel, no reason to fork it just for this. - All the required functions for drag/drop support should be implemented though that doesn't matter much anymore when used in QML.. We *could* do that (my comment in the code says not sure, I'm still not sure) -- but it would kill any hopes for core/gui separation, since a user- initiated copy operation can trigger conflict dialogs etc. And different apps might want different things to happen on drop (e.g. think of kdevelop, where drop might mean add to project, not copy here). But I'm open to being convinced of a useful default implementation if you think this is missing. Remove: - QModelIndex indexForItem( const KFileItem ) const; - QModelIndex indexForUrl(const QUrl url) const; * reasoning for the above: these are convenient functions, they don't belong in this class. If a user wants them then just subclass it and add those convenient functions. Well, that's the point of convenience, to be convenient. Honestly I don't see the problem you have with these two small methods, and I'm sure that if you use lxr.kde.org you'll find plenty of use cases for them. - void expandToUrl(const QUrl url); * reasoning: expanding to some folder can be done bet using setRootIndex (in the view) Wrong. setRootIndex changes the root, while expandToUrl is about expanding in a tree. It took enough time to get that functionality right, trust me when I say it's not trivial. And the fact that you don't need it in a QML context (for lack of trees) doesn't mean the functionality can be simply removed, there are qtreeviews on top of KDirModel. - void itemChanged( const QModelIndex index ); * perhaps as an internal API, certainly not visible for the outside world. Yes, the only user (KMimeTypeResolver) is already deprecated, so I agree on this one. - static QListQUrl simplifiedUrlList( const QListQUrl urls ); * Not the right place. Agreed, but it's needed inside KDirModel and outside. Better suggestions for moving this code are welcome, but these don't make sense: Either re-implement the model How does that help with the internal call to simplifiedUrlList? or use KIO::ListDir (or even KDirLister) I don't see the relation at all. - void requestSequenceIcon(const QModelIndex index, int sequenceIndex); - void needSequenceIcon(const QModelIndex index, int sequenceIndex); * Yes, but should be done internally and automatically. The user should only have an option to enable/disable this. Not sure how this works exactly. Feel free to adapt kfile/kfilepreviewgenerator.cpp. Overall, I'm very much against a V2 with only half the implementation. What happens then? How do we ever remove V1, if V2 doesn't have what we need? We'll stay with two competing implementations
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Sat, Dec 29, 2012 at 12:44 PM, David Faure fa...@kde.org wrote: On Friday 28 December 2012 02:50:53 Mark wrote: Hi, -- Be sure to read all of this (long!) mail or parts won't make sense! -- -- cross posting to frameworks and KCD since it concerns both -- I'll let the k-c-d people come here if they want to participate. cases that would be oke, but if you have really massive folders then having a list of - let say - 100.000 files/folders in KFileItem objects begins to be quite taxing for the CPU. That alone isn't an issue, but the fact that you won't even see those 100.000 items in any view makes it quite wasteful to even store it. So what i want to do is store a big (much smaller in memory) UDSEntry list where KFileItem objects are lazy loaded when actually needed. That would be a lot less taxing for the CPU and memory. CPU-wise, we could do the lazy initialization inside KFileItem itself, and the result would be pretty much the same, without exposing everyone to rather internal UDSEntries. Memory-wise you're right, though, KFileItem adds quite a bunch of data. Maybe this could be changed so that it stores its data directly into the UDSEntry, even when created from a local path directly (no UDSEntry as input). That certainly is an interesting alternative approach! Just a little side note, is it possible to get rid of KFileItem and use QFileInfo? Though i'm guessing it's not possible due to Qt not being as powerful as KIO in the file stuff. Also the caching in KDirListerCache would very likely be a lot smaller when using a UDSEntryList. You'll end up adding tons of methods to UDSEntry, to make this possible, so basically you'll turn UDSEntry into KFileItem, API wise. This doesn't make sense to me, better make KFileItem slimmer internally, and keep the API. UDSEntry is the raw storage [for things that come from a kioslave], KFileItem is the API on top [plus support for things that don't come from a kioslave]. Better keep this separated (e.g. UDSEntry is enough on the slave side), and fix the memory usage of KFileItem by changing its implementation. This kinda depends on it. Why would you cache? Because something is slow. If the reason for it being slow is gone then you don't need a cache at all. That's my aim here. Making it fast enough for the cache to be removed. Perhaps the UDSEntry should have all the values of KFileItem where KFileItem would just access those values. That would make the UDSEntry a little more heavier but would make KFileItem nearly free. --- KDirModelV2 API (on top of the functions that have to be re-implemented) - void setDirLister( KDirLister* dirLister ); - KDirLister* dirLister() const; - KFileItem itemForIndex( const QModelIndex index ) const; - void setAdditionalRoles(const QHashint, QByteArray roleNames) - The column names should get some defaults that can also be used in QML. This can be done in the current KDirModel, no reason to fork it just for this. True. When i wrote that i was thinking about all the other changes in KDirLister(V2) thus i thought it would heavily influence the KDirModel implementation as well. Thus a V2 of that one. But you're right, it doesn't need a V2, just a big cleanup :) - All the required functions for drag/drop support should be implemented though that doesn't matter much anymore when used in QML.. We *could* do that (my comment in the code says not sure, I'm still not sure) -- but it would kill any hopes for core/gui separation, since a user- initiated copy operation can trigger conflict dialogs etc. And different apps might want different things to happen on drop (e.g. think of kdevelop, where drop might mean add to project, not copy here). But I'm open to being convinced of a useful default implementation if you think this is missing. Well if that's the case then i would go for not implementing it at all. Users can still make a custom KDirModel and implement it if they like. Remove: - QModelIndex indexForItem( const KFileItem ) const; - QModelIndex indexForUrl(const QUrl url) const; * reasoning for the above: these are convenient functions, they don't belong in this class. If a user wants them then just subclass it and add those convenient functions. Well, that's the point of convenience, to be convenient. Honestly I don't see the problem you have with these two small methods, and I'm sure that if you use lxr.kde.org you'll find plenty of use cases for them. - void expandToUrl(const QUrl url); * reasoning: expanding to some folder can be done bet using setRootIndex (in the view) Wrong. setRootIndex changes the root, while expandToUrl is about expanding in a tree. It took enough time to get that functionality right, trust me when I say it's not trivial. And the fact that you don't need it in a QML context (for lack of trees) doesn't mean the functionality can be simply removed, there are qtreeviews on top of KDirModel. Missed that one. Oke, should not
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Saturday 29 December 2012 11:44:20 David Faure wrote: On Friday 28 December 2012 02:50:53 Mark wrote: Another thing is the UDS_EXTRA and UDS_EXTRA_END. I seriously doubt that the functionality is even used anywhere. Yes, this got lost with the move from the old konq views to dolphin. UDS_EXTRA is used in KDE PIM (NNTP slave and KNode), and according to lxr in a bunch of other places as well. regards, Volker signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDirModelV2, KDirListerV2 and UDSEntryV2 suggestions
On Sat, Dec 29, 2012 at 3:27 PM, Volker Krause vkra...@kde.org wrote: On Saturday 29 December 2012 11:44:20 David Faure wrote: On Friday 28 December 2012 02:50:53 Mark wrote: Another thing is the UDS_EXTRA and UDS_EXTRA_END. I seriously doubt that the functionality is even used anywhere. Yes, this got lost with the move from the old konq views to dolphin. UDS_EXTRA is used in KDE PIM (NNTP slave and KNode), and according to lxr in a bunch of other places as well. regards, Volker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hmm, http://lxr.kde.org/ident?i=UDS_EXTRA Guess it should stay. UDS_EXTRA_END seems to be used in a few places to detect the end of a UDS_* list. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
