> On Nov. 29, 2012, 7:48 p.m., Pino Toscano wrote: > > kioslave/file/file_unix.cpp, line 363 > > <http://git.reviewboard.kde.org/r/107520/diff/1/?file=96853#file96853line363> > > > > This would be QFile::decodeName, not QString::fromLocal8Bit... but you > > don't need it either, since you have "path" already. > > Mark Gaiser wrote: > Am i allowed to use the path variable? Considering that it isn't decoded.. > Also, i can't use QFile::decodeName directly because it returns a > QByteArray. QDir::setCurrent wants to have a QString. Usually that wouldn't > be an issue. However, there are some compile parameters set that forbids me > from doing that so i have to use the QString::from... functions or the data > variable. > > Pino Toscano wrote: > > Am i allowed to use the path variable? Considering that it isn't > decoded.. > > Uh? "path" is a QString, hence unicode. > > > Also, i can't use QFile::decodeName directly because it returns a > QByteArray. > > Apparently, reading the documentation is hard: > static QByteArray encodeName(const QString &fileName); > static QString decodeName(const QByteArray &localFileName); > > > QDir::setCurrent wants to have a QString > > Yes, an unicode string, and it will do the right job to decode it in the > proper way for the current OS / file system.
ahh right, i was responding based on "encodeName" (which is used in the code) and i mixed that up with "decodeName". Sorry for the confusion. Guess i can just use path in the QDir::setCurrent function then. - Mark ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107520/#review22785 ----------------------------------------------------------- On Nov. 29, 2012, 7:33 p.m., Mark Gaiser wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107520/ > ----------------------------------------------------------- > > (Updated Nov. 29, 2012, 7:33 p.m.) > > > Review request for kdelibs and David Faure. > > > Description > ------- > > listDir is batching only in a vague manner. It required to have details set > to something bigger then 0 and required to know the amount of files that > where going to be send. Even then it was fixed to broadcast only the first > 100 entries followed by _everything_ that comes after it. For more details, > look at the diff. If you did happen to do a request with details set at 0 > (thus only the filename and filetype are stored) then a different code path > was taken where it wasn't even possible to batch. > > I changed this to do time based batching. Now it broadcasts all the entries > it currently has after 300ms have been passed. In normal situations on the > local file system that means that you will never see batching. You will start > to see them if you hit folders with 10.000+ entries in then (for a SSD that > is). For the slower HDD drives you probably see more batching. > > In the worst case scenario you could find yourself in the situation that 1 > entry is broadcasted every 300ms. That is only on very slow external devices > or internet places. > > The advantage of batching (just repeating that here since it's currently not > working in any KDE app) is that you can start showing results to the user > without all the results being in. This gives the user a "feeling" that it's > fast even though KIO might still be working hard to get all entries in. > Dolphin is one app in particular that can really make use of this. Currently > it doesn't do that. IT waits till all the results are in. > > While working on this, i also updated the style of the FileProtocol::listDir > function and greatly simplified how it lists the directory. Now the actual > listing just follows one code path instead of one for details 0 and one for > the rest. > > I'd like to get this in kdelibs for KDE 4.10 because it is a bugfix even > though there is no bug report. > > > Diffs > ----- > > kio/kio/slavebase.h 0bdb146 > kio/kio/slavebase.cpp 8f8ff03 > kioslave/file/file_unix.cpp 2b47b7c > > Diff: http://git.reviewboard.kde.org/r/107520/diff/ > > > Testing > ------- > > I tested this in various ways: > (SSD) 100.000 entries in a folder with details set to 0: 1 signal with all > entries > (SSD) 100.000 entries in a folder without details set (all info): 2 or 3 > signals each with between 20.000 - 50.000 entries > (slow ftp) ftp://ftp.mirror.aarnet.edu.au/pub/archlinux/extra/os/x86_64/ > results start slowly with 20 - 50 per signal and quickly climb up. > Ran the kio test cases. Apparently i have a "failed" for kio-krununittest, a > testcase that David Faure has fixed if i'm right. > Updated the documentation to not mention the total files anymore. KioSlaves > can still set it, but it's just unused for the listDir now. > Last, running with this now and i haven't seen any issues so far. > > > Thanks, > > Mark Gaiser > >
