RCC for icons - update: Re: Icons installed by apps

[Jaroslaw Staniek]

On 24 September 2015 at 23:04, David Faure <faure at kde.org> wrote:

> On Tuesday 22 September 2015 18:44:47 Jaroslaw Staniek wrote:
> > On 22 September 2015 at 14:17, Jaroslaw Staniek <staniek at kde.org> wrote:
> > > Hello,
> > > A couple of related questions while wrestling with issues such as [1].
> > >
> > > Let's assume Kexi app installs some icons to
> > > PREFIX/share/kexi/icons/oxygen/32x32/places/ or
> > > PREFIX/share/kexi/icons/breeze/32x32/places.
> > > Can these be searched by the icon engine?
> >
> > Sorry for adding more info to clarify.
> > UserIconSet is deprecated so I guess this functionality is deprecated
> too...
> > since QIcon::fromTheme() apaprently isn't able to find app icons.
> >
> > I've seen quite a few KDE apps compiling-in their (usually custom
> > action) icons into qrc instead.
> >
> > I've not seen other app that do what Calligra apps do:
> > using icons fron share/calligra/icons (in kdelibs4 times
> > share/apps/calligra/icons).
> >
> > Comments?
>
> I guess qrc is actually better. Otherwise app1 might start depending on
> icon installed
> by app2 (without really noticing). And this simplifies deployment (and
> speeds up lookup).
>

Hi David & All. ​I am back to this topic.

I've got some experiments. .rcc files for icons is a nice thing, not to
big, obviously quick to deploy.

There's *rcc  --project*
(Outputs a qrc resource file containing all files from the current
directory)

Now, how to deal with it?
Is a variant of KIconLoader needed that works with QResources?
Obviously we need a QIconEngine-level solution to have icons available on
demand instead of such hacks:

QIcon tableIcon;

tableIcon.addPixmap(QPixmap(":/icons/16-actions-table.png"));

tableIcon.addPixmap(QPixmap(":/icons/22-actions-table.png"));

tableIcon.addPixmap(QPixmap(":/icons/32-actions-table.png"));

someQAction->setIcon(tableIcon)


One approach is to build rcc out of a fresh installed
PREFIX/share/icons/breeze/* files and does with the paths in a standard
way. This is why I am looking at opportunity of reusing the logic of
KIconLoader. Or maybe it's all silly because it's ready to use and I missed
something?

To build .rcc's I am using cmake's qt5_add_binary_resources() for Qt>=5.5
with some add_custom_command() fallback for older Qt.

At higher level, I was thinking about a reusable implementation, that
eventually would maybe land in KIconThemes if there's interest. Or maybe as
a separate tiny lib.
I think the solution with a packaged breeze icons resource working
out-of-the box could be a good (lightweight) addition for non-Plasma
(non-Linux?) users of KF5, to popularize KF5. They grab the icons package
and icons just work without thousands of files, caching, etc. 'One in a
million' would of these users would be interested in theming.
And this solution is generally usable for any Qt apps even if nothing else
from KF5 is used: just load .rcc dynamically and things work.

That's just a lower priority. My actual test is the application of the idea
for Kexi.

PS1: Feature I'm also considering: converting svgs to pngs before creating
the rcc files. Not sure but svgs can be included too, for general use in
big sizes and for high DPI screens.

PS2: I have been beaten by situations such as KToolBar setting 0-size icons
by default.
This is in a Windows env where no themes are (properly) installed. If the
rcc-based solution is in use I would imagine that ideally all the KF5 code
detects this somehow and would not look for xdg standard themes through the
classic KIconLoader but silently adapt so the rcc resource works great.
Just a dream.

PS3: A bonus of not having thousands of icon files is that some KDE apps
are more capable to become 'portable apps' (in the http://portableapps.com
meaning).
​

>
> What I don't know however is whether artists consider that these icons
> should be themeable...
>
> BTW did you look into the xdg icon spec?
> I guess it's not there?
> On the other hand it doesn't prevent doing it since it's not about sharing
> icons; it's just harder
> to convince Qt to look there :) (I think qiconengine and kiconengine
> should stay compatible,
> so that we can even consider switching to qiconengine one day).
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160218/c3ec6ce5/attachment-0001.html>