This makes the code a bit cleaner (in my opinion) and we can have more control over the QThreadPool used for fetching file icons.
Behaviour changed:
- File icon cache is now a singleton so cached icons can be shared across multiple
KisMainWindow's. - Limit to at most 2 threads for icon generation to prevent it from using up too many resources.
- Don't generate a high-DPI thumbnail. The way we used to generate high-DPI icons relies on the devicePixelRatio of the main window at the time of calling
setFiles, so the icons can be in the wrong size if the window ever moves to a different monitor. Since the cache is now application-wide, it is a bit trickier to implement, so I decided to not handle it for now. (I do have a rough idea how it can be implemented better if we need to.)
Beyond this MR:
- Look into lazy loading of the thumbnails. Because the default maximum recent items count is now 100, we don't really want to load all of them every time Krita starts. Especially since really big files can take a lot of memory and CPU time to process. We can load whatever visible on the welcome screen, but for the rest it should be better to delay loading until the user actually scrolls the list.
- Shall we place a maximum limit on the file size or pixel count and not generate thumbnails of really big images?
- Perhaps we should make a persistent icon cache to reduce the processing needed on startup?
- Reload the file icon when saving over it (https://bugs.kde.org/show_bug.cgi?id=447492)
- If the file is being added to the list by being opened in or saved from Krita, we can just generate the thumbnail from the opened document directly.
- Refactor the rest of recent file list handling to be application-global instead of per-KisMainWindow.