As we are a Kirigami application, this makes use of the Kirigami icon item, which in turn allows us to use more types of icons, and not just QIcons. This also allows for remote icons (once a patch has been added to Kirigami to allow for this, and until then it fails gracefully by simply failing to load any icon).
Details
Diff Detail
- Repository
- R134 Discover Software Store
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
I did consider adding a loader-based fallback system to this, but that would put a loader inside the listviews, and i'm not sure it really gains us a great deal... If we instead accept Kirigami 2.1 for this (or even 2.0), DesktopIcon will happily accept the url, and if it is the pre-2.2 version it will simply show nothing for those entries that request a remote picture (that is, the code will be much more pleasant to maintain when compared to such a fallback system, at the cost that the visual experience will be at worst slightly degraded). I think it is an acceptable cost, if we can trust that Kirigami 2.2 is released sometime in the not too distant future.
if we can trust that Kirigami 2.2 is released sometime in the not too distant future.
Will it be released publicly by Monday?
It won't, but the bit that would otherwise cause issues is not used right now, so this causes no regressions :) (The bit which might cause an issue is the (much smaller) D5768, which won't be merged before Kirigami 2.2 has a release)