Use QSvgRenderer for SVG icons #247
Conversation
`QSvgRenderer` is used with a cache for both ordinary and colorized SVG icons. In this way, LXQt's icon handling cannot be broken by intruding icon engines, which register themselves for "svg" (see #246). Moreover, it does not depend on a specific code structure of `qtsvg` or any other icon engine.
| } | ||
| hCol = pal.highlight().color().name(); | ||
| } | ||
| QString key = QLatin1String("lxqt_") |
There was a problem hiding this comment.
Just suggestion... wouldn't it be better to to use the same key structure for both ScalableFollowsColorEntry & ScalableEntry? Or be the one at least prefix of the extended?
There was a problem hiding this comment.
The only difference is that, in ScalableFollowsColorEntry, we need three colors (not the whole palette) but we don't need them in ScalableEntry.
BTW, what do you think about increasing QPixmapCache limit? I didn't think that was needed but wanted to ask your opinion.
There was a problem hiding this comment.
but we don't need them in ScalableEntry.
Sure... but then wouldn't it be better to have the same fixed-width prefix... like:
QString key = QLatin1String("lxqt_")
% filename
% HexString<int>(mode)
% HexString<int>(state)
% HexString<int>(size.width())
% HexString<int>(size.height())
% txtCol % bgCol % hCol;..and can't the concatenation of *Col allow a collision?
what do you think about increasing QPixmapCache limit?
Never looked into that. But if we need to increase...then I would vote for allowing it to be configurable.
There was a problem hiding this comment.
but then wouldn't it be better to have the same fixed-width prefix... like:
No objection from me if you prefer it. No collision will happen either. Will do it soon.
But if we need to increase...then I would vote for allowing it to be configurable
I agree. Haven't found a real use case yet; just an idea.
There was a problem hiding this comment.
Done; made the cache keys similar to each other.
QSvgRender itself only support SVG 1.2 Tiny for rendering so SVGs that more complex might not able to rendered properly. Thus, some DE like KDE and DDE provides their own Qt icon engine and registered them as for SVG icons, and seems that causes libqtxdg have issues, so lxqtGH-247 was there. But user or DE might still want to install or provide Qt image formats plugins for better SVG files/icons rendering, using QSvgRender will stop the Qt image formats plugin from being used. Using QImageReader will still allow us avoiding the usage of Qt icon engines, but kepts the ability to make Qt image formats plugin to work properly. This patch originally provided by @zccrs
From: lxqt/libqtxdg#247 Use QImageReader instead of QSvgRender for XdgIconLoader QSvgRender itself only support SVG 1.2 Tiny for rendering so SVGs that more complex might not able to rendered properly. Thus, some DE like KDE and DDE provides their own Qt icon engine and registered them as for SVG icons, and seems that causes libqtxdg have issues, so lxqt/libqtxdg/pull/246 was there. But user or DE might still want to install or provide Qt image formats plugins for better SVG files/icons rendering, using QSvgRender will stop the Qt image formats plugin from being used. Using QImageReader will still allow us avoiding the usage of Qt icon engines, but kepts the ability to make Qt image formats plugin to work properly. This patch originally provided by @zccrs Issue: linuxdeepin/developer-center#6480
From: lxqt/libqtxdg#247 Use QImageReader instead of QSvgRender for XdgIconLoader QSvgRender itself only support SVG 1.2 Tiny for rendering so SVGs that more complex might not able to rendered properly. Thus, some DE like KDE and DDE provides their own Qt icon engine and registered them as for SVG icons, and seems that causes libqtxdg have issues, so lxqt/libqtxdg/pull/246 was there. But user or DE might still want to install or provide Qt image formats plugins for better SVG files/icons rendering, using QSvgRender will stop the Qt image formats plugin from being used. Using QImageReader will still allow us avoiding the usage of Qt icon engines, but kepts the ability to make Qt image formats plugin to work properly. This patch originally provided by @zccrs Issue: linuxdeepin/developer-center#6480
QSvgRendereris used with a cache for both ordinary and colorized SVG icons. In this way, LXQt's icon handling cannot be broken by intruding icon engines, which register themselves for "svg" (see #246). Moreover, it does not depend on a specific code structure ofqtsvgor any other icon engine.