There's no proper replacement for KIcon

[Kevin Krammer]

On Thursday, 2014-09-11, 17:56:38, Eike Hein wrote:
> On 11.09.2014 17:22, Kevin Krammer wrote:
> > Hicolor is there for cases where the setup fails to provide any workspace
> > or distribution specific theme.
> 
> Yes. So I'm thinking ahead and telling you how that "setup" looks
> like for a workspace:
> 
> - Write a Qt platform plugin. Needs coding chops. We have them. What
>    about workspaces which don't? What about all the other toolkits be-
>    sides Qt?
> 
> - Swap out icons in hicolor.
> 
> Which do you think happens?

Depends on the wanted results.

A platform plugin provide platform integration which icons are only a small 
part of. If the platform vendor wants Qt application to properly integrate 
with their choice of workspace, they will have a platform integration plugins.

If they just want to have icons, they are very well able to ship their own 
version of hicolor fallback icons.
This does not conflict with having a non-broken hicolor theme package to start 
with.

> > 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?
> 
> Because making Qt aware of an explicit theme involves writing a Qt
> platform plugin. It means if you're a sys admin / distro you can no
> longer solve your problem on the spec level (unless you swap out
> icons in hicolor), you need to be aware Qt exists. Seems like a
> layering violation to me.

As I said above, it depends on the level of integration you'd like to achieve.
There are lots of integration points provided by said plugin.

> > 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.
> 
> No, but it makes it a lot easier for distros to provide a complete
> fallback (-> installing Oxygen or something else, setting it as
> preferred fallback). It's less work than maintaining a complete hi-
> color no one can agree on.

I don't see why it would be difficult to agree on having a non-broken 
fallback.

> > Or do you mean install the custom theme twice, once as itself and once as
> > hicolor?
> 
> Wait - I think I now understand why we're having trouble
> communicating about this.
> 
> You think a distro has the option to install Oxygen *as*
> hicolor, right, making my preferred fallback thing seem
> redundant?
> 
> That's not so - because numerous apps install app icons
> *into* the hicolor folder structure, including KDE apps,
> and those can conflict with the icons in a theme. For
> distro packagers that means they'd have to fix numerous
> package installs to eliminate those conflicts.

No, I mean providing their own hicolor theme if they want to (ab)use the 
fallback as their integration point.

I really have to read the spec soon, but I have my doubt that it lists any app 
specific icons. Thus installing such into its paths should not conflict with 
anything already there.

> So using any given theme *as* hicolor doesn't fly without
> manual merging/maintenance work for packagers, which is
> what I suggest to avoid with a 'preferred system fallback'
> config knob.

Assuming that a vendor wants to override the default hicolor package, then yes 
that will obviously require maintenance. This is no different with any other 
deviation from upstream.

Again, having a shared setting, exposed via whatever mechanism (env variable, 
X11 property, file, ....) is orthogonal to having a working fallback.

The fallback is hit when no other means of lookup, whether configurable or 
hardcoded, resulted in a matching icon.
So it *must* at least contain all icons that are specified in the spec, it is 
an icon loader's last resort.

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/20140912/ca0c979f/attachment.sig>