There's no proper replacement for KIcon

[Kevin Krammer]

On Thursday, 2014-09-11, 17:05:43, Eike Hein wrote:
> On 11.09.2014 16:09, Kevin Krammer wrote:
> > Why would hicolor be distro/ISV specific?
> 
> Because a hicolor theme everyone likes visually isn't going
> to happen. People will want to modify what's in that fall-
> back for theming reasons, and distros theme to differentiate
> themselves.

Why would anyone want to change the fallback?
The fallback is something you never ever want to see, it is a worst case 
scenario puffer.
Like the safety net in a circus arena.

I think what you mean is a default, like us using Oxygen/whatever, GNOME using 
Tango/whatever, etc.

Hicolor is there for cases where the setup fails to provide any workspace or 
distribution specific theme.
Its purpose (I have still not read the spec but that is the only thing that 
makes sense to me) is to make sure there is an icon if anything else has 
failed.
A shared resource to avoid every application having to ship fallbacks for each 
used icon.

> In the "hicolor as fallback" scheme, there are two ways to
> affect what icons actually show in KF5 apps outside Plasma:
> 
> - Make sure this environment outside Plasma, whatever it is,
>    has a Qt platform plugin available that reads some setting
>    somewhere that overrides hicolor by specifying a theme.

Right, this is what a distributor or other workspace would do if they care 
about theming as a means of differentiation.

>    (This is how Plasma itself solves this.)

Exactly.

> - Manipulate what icons are actually in hicolor.

Sure, if somebody wants to install their icon theme instead of hicolor, why 
not.
But why not just have your theme as an explicit theme like everyone else and 
only get your theme in case the fallback path is triggered?

Or do you mean install the custom theme twice, once as itself and once as 
hicolor?

> If we introduce a "preferred system fallback theme" config
> option in the spec that overrides hicolor, and make Qt aware
> of it, that avoids either work, which is more extensible to
> new environments.

Sharing a setting that indicates a default theme name is of course a good 
goal, doesn't however fix the problem of the fallback being incomplete.

I read that non Qt based systems use XSettings to exchange that information 
(on X11 only of course) so maybe we can have that in Qt as well?

And come up with a way to do something equivalent on Wayland?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140911/39fd8355/attachment.sig>