[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: RCC for icons - update: Re: Icons installed by apps
From: Jaroslaw Staniek <staniek () kde ! org>
Date: 2016-03-07 14:53:21
Message-ID: CAOj7QQ0paC3k7VMwFGO+Q4-PMAUQrik3HDH1EKnxw0incqSBoQ () mail ! gmail ! com
[Download RAW message or body]
On 7 March 2016 at 14:45, René J.V. <rjvbertin@gmail.com> wrote:
> On Monday March 07 2016 12:41:52 Jaroslaw Staniek wrote:
> >I am trying to use app-defined icons through QIcon::fromTheme() in Kexi.
>
> 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.
>
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.
Please also note I am not mixing breeze theme and app's breeze icons. They
are separated.
> >Without that I'd have to duplicate logic of icon themes just to make
> QIcon::fromTheme() work cross-platform.
>
> 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?
>
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.
>
> 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.
>
> 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?
>
With all due respect. Dunno. I am writing this email in a 2GiB large email
client (GMail in Firefox).
With thousands of cached icons and copies of jQuery. We're still super
light.
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.
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.
My kexi_breeze.rcc is 184
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.
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.
2016 calling :) The resource files are easily handled in my years-old
smartphone, so...
There's nearly zero stat() calls for icons discovery instead of thousands
per (even tiny) app.
And packagers can easily package breeze.rcc (I'd recommend this in a
README.PACKAGERS file).
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
[Attachment #3 (text/html)]
<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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic