This avoids blocking when the folder is on a slow mount. It is quite a niche feature anyway.
Details
Diff Detail
- Repository
- R241 KIO
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Would this be a satisfactory way to also read a custom icon from the .directory file? If you add that, I'll be happy to abandon D13083: Respect custom directory icons in iconNameForURL().
The problem is that now this is done for every single file being listed, rather than on demand. In a directory with 1000 subdirs, this would look for 1000 */.directory files, while the user is typically only going to hover one or two... I agree that blocking a different process is much better than blocking the GUI of course, I just worry about the overall impact on performance in the "normal" case (local dir, lots of subdirs).
Maybe this should be done in process (so it's on demand) but with an async API, so the file reading/parsing can be done in a thread...
Not really as part of KFileItem then, but a KIO::FetchFileCommentJob or something like that.
Theres's also the directory icon reading which potentially blocks, so doing both in the KIO slave improves the situation without having to introduce new API and rewrite everything and the kitchen sink.