On 7 March 2016 at 14:45, René J.V. <rjvber...@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
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
