<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 7 March 2016 at 14:45, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</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"><span class="">On Monday March 07 2016 12:41:52 Jaroslaw Staniek wrote:<br>
>I am trying to use app-defined icons through QIcon::fromTheme() in Kexi.<br>
<br>
</span>That sounds inherently wrong unless the application adds icons to specific themes. Icons that are specific to an application are (almost) by definition not part of a theme, so expecting QIcon::fromTheme() to return them seems a bit of a misunderstanding.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I am using the icons theme infra for this. Alternative would be to duplicate the code to achieve exactly the same. QIcon(filename) does not even support multiple sizes; you need to code this. Note how a Kate plugin I mentioned above uses hardcoded ":/katesql/pics/16-actions-sql-field-pk.png" file.<br>Please also note I am not mixing breeze theme and app's breeze icons. They are separated. <br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
>Without that I'd have to duplicate logic of icon themes just to make QIcon::fromTheme() work cross-platform.<br>
<br>
</span>Why? Why not do as Kate and use QIcon(":/icon-from-rcc") instead of QIcon::fromTheme() for app-specific icons that should be independent of the user's icon theme choice, and ::fromTheme() for those icons that are supposed to reflect his/her choice of theme?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Because I am not reflecting the choice in Kexi's icons. The only that are produced (takes weeks) and referenced in docs are the breeze ones. Anyone is free to start project aimed at supporting another theme. This is a switch in philosophy to boost the quality, and I accept you may disagree. But how icons are packaged distributed should reflect the development process and priorities of the app project.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I don't think there's any need whatsoever to duplicate (reimplement) the logic of icon themes. AFAIK, QIcon::fromTheme() will work anywhere once you define an icon theme search path and the expected icon theme is installed somewhere in that path.<br>
<br>
BTW, am I right that using a builtin binary rcc icon set could make you lose in terms of memory (RAM) footprint overhead what you gain in terms of disk space overhead?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">With all due respect. Dunno. I am writing this email in a 2GiB large email client (GMail in Firefox).<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">With thousands of cached icons and copies of jQuery. We're still super light.<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">As David Faure said not once here, technically we just don't have KDE apps anymore. We have Qt apps. We can't assume themes are installed, properly installed, or caching is in place. Optimizations is the 1% remaining thing.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I know no user who abandons software because of such things. Mac had universal binaries for years, with interesting growth in size. FatELF, application containers, all these are approaches that spend a few bytes in exchange for convenience, security, etc. <br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"></div><span class=""><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">My kexi_breeze.rcc is 184</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">k an full (unoptimized) breeze.rcc is 14M compressed 35MiB fully uncompressed, while my wallpapers on just 2 screens are 18M compressed, ~120MiB in graphics RAM. And many of the icon file take >=4096 bytes despite being 2048 bytes large.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I guess you also know that random-accessed files are mmapped and read on demand. Though I bet a 14M file will be read-ahead on any todays system.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br><span class="">2016 calling :) The resource files are easily handled in my years-old smartphone, so...<br></span><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><span class="">There's nearly zero stat() calls for icons discovery instead of thousands per (even tiny) app.</span></div></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">And packagers can easily package breeze.rcc (I'd recommend this in a README.PACKAGERS file).<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br></div></span></div></div>-- <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>