[Kexi-devel] RCC for icons - update: Re: Icons installed by apps

Thu Feb 18 12:55:18 UTC 2016

And BTW, just found this.. so adding CC for Lars and Simon.

https://mail.kde.org/pipermail/kde-optimize/2005-June/001096.html

On 18 February 2016 at 12:05, Jaroslaw Staniek <staniek at kde.org> wrote:

>
> 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
>

-- 
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/kexi-devel/attachments/20160218/a350855c/attachment.html>