<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 February 2016 at 18:25, Kåre Särs <span dir="ltr"><<a href="mailto:kare.sars@iki.fi" target="_blank">kare.sars@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Thursday, February 18, 2016 02:51:58 PM René J.V. Bertin wrote:<br>
> On Thursday February 18 2016 13:55:18 Jaroslaw Staniek wrote:<br>
> >>> > since QIcon::fromTheme() apaprently isn't able to find app icons.<br>
><br>
> Care to explain? QIcon::fromTheme() doesn't find anything "out of the box"<br>
> on OS X (and I presume on MS Windows), but that is only because no theme<br>
> search path is set on those platforms. When you add the standard XDG icon<br>
> repository to the icon search path on OS X, even "pure" Qt5 application<br>
> will start showing icons all over if you have an icon theme installed --<br>
> including in widgets that should not have icons according to the HIG. Also<br>
> on OS X, fromTheme() will only return the application icon (as in the icon<br>
> shown in the Finder) if the current theme defines that same icon for the<br>
> calling application, and the theme search path is set of course. In all<br>
> other cases it will not, because the application icon is not defined<br>
> through a theme on OS X (nor is it on MS Windows, I presume).<br>
> >> I think the solution with a packaged breeze icons resource working<br>
> >> out-of-the box could be a good (lightweight) addition for non-Plasma<br>
> >> (non-Linux?) users of KF5, to popularize KF5. They grab the icons package<br>
><br>
> Popularise, with Breeze "art"work? O:-)<br>
> Anyway,  I don't think "grabbing an icon package" will work on OS X, not if<br>
> you want to create standalone app bundles which by definition contain<br>
> everything they need.<br>
> >> and icons just work without thousands of files, caching, etc. 'One in a<br>
> >> million' would of these users would be interested in theming.<br>
><br>
> I'd up that estimate if we're still talking about Breeze icons here O:-)<br>
><br>
> >> PS2: I have been beaten by situations such as KToolBar setting 0-size<br>
> >> icons by default.<br>
><br>
> Partly this is because almost no KF5 code uses the fallback argument of<br>
> QIcon::fromTheme() explicitly, which means that the function returns an<br>
> empty icon if the search fails. In particular, statements like<br>
><br>
> app->setWindowIcon(QIcon::fromTheme(programName))<br>
><br>
> should read<br>
><br>
> app->setWindowIcon(QIcon::fromTheme(programName, app->windowIcon()))<br>
><br>
> >> This is in a Windows env where no themes are (properly) installed. If the<br>
> >> rcc-based solution is in use I would imagine that ideally all the KF5<br>
> >> code<br>
> >> detects this somehow and would not look for xdg standard themes through<br>
> >> the<br>
> >> classic KIconLoader but silently adapt so the rcc resource works great.<br>
> >> Just a dream.<br>
><br>
> If your rcc resource corresponds to the resource mentioned in the<br>
> QIcon::fromTheme() documentation (I think that talks about "qrc") and if I<br>
> interpret that documentation correctly then yes, code using that function<br>
> will find icons from the rcc/qrc "builtin" resource over those in xdg<br>
> themes (if the XDG icon repository is even in the icon theme search path).<br>
> >>> What I don't know however is whether artists consider that these icons<br>
> >>> should be themeable...<br>
><br>
> I think icon artists will consider that you should touch their icons (for<br>
> theming or anything else). They will probably also consider that their<br>
> icons are the "best" but they really should also consider it a right for<br>
> anyone to use other icons ;)<br>
><br>
<br>
</div></div>The breeze.rcc file way is actually how Christoph solved it in Kate for<br>
Windows and OSX. We create an .rcc file from the breeze icons and at start-up<br>
we search for the file in QStandardPaths::DataLocation and if the file is<br>
found we load it with  registerResource() and add ":/icons" to the<br>
themeSearchPaths. (kate.git/icons.h)<br>
<br>
Christoph also added ":/icons" to the search path in kicontheme so that xmlgui<br>
toolbars and friends also get the icons from the .rcc file.<br>
<br>
We get all the same icons as on Linux neatly in one file :)<br>
<br>
breesze's symlinks was a problem on windows, but I created a small application<br>
to replace the symlinked files with an alias pointing to the target file -><br>
smaller .rcc file :)<br>
</blockquote><div> <br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Thanks for reminding this, ​​Kåre​!<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I went this way and started with manual creation of rcc on Windows.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Then I've added some cmake code for creation of an rcc for app icons (Kexi). <br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I think the code would be usable to the same for breeze_icons.rcc and have it in breeze-icons.git, and maybe by default for non-XDG platforms. So people can build the fresh file very easily. Then a more flexible loading code could be put into the kiconthemes, and we're mostly done. Things should work with qmake too, so the list of projects potentially interested -- grows.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Now I have two rcc files, registering app's icons rcc first, then the global breeze one, what gives name overriding as expected. Not sure I will want to override eventually, it's not good idea but nice to have as emergency (I needed it once).</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I'll be experimenting with the approach for _libs_ such as kproperty, that are almost Qt-only, and have GUI bits so they need icons. Sometimes lib authors even want to offer a stripped-down option for building their libs. The rcc icons approach looks nice for them too.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Finally, I don't need to endlessly update the filenames for ecm_install_icons(), not even the GLOB command is needed.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">In terms of Linux packaging, there can be still one rcc breeze package to create, 13MiB uncompressed, shared. So in 'worst' case two instances of breeze icons sit in the system, where the second one is the traditional. Not bad. If I had to develop a 'light' Qt desktop (think LXQt?) I'd look at rcc files.<br></div></div></div><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>