On 09/03/2014 10:14 PM, Albert Astals Cid wrote:
Are you suggesting it is acceptable for my apps to regress (compared to their
kdelibs4 version) and have no icons because they are not being run under a
Plasma session?
No, I'm not. The context my reply is about was quoted in
my email.
I honestly didn't even understand your initial mail to
the list. There's a vague claim about QIcon::fromTheme
"obviously" not doing something, but I guess it's not
obvious enough for me.
So no, I:
a) Did not kill your puppy. Puppies are awesome. Mostly.
b) Think your attack tone has no place on this list.
Some advice: Your inquiry could have been phrased as a
question instead ("am I getting this right? if so, any
help?"). Or it could have provided a little more analysis
of the problem you're seeing at least. This is what
"common ownership" on http://manifesto.kde.org/ is about,
BTW.
Here's my understanding of how this works, which may
be wrong: QIcon::fromTheme() ends up calling into the
currently active platform plugin when it needs to
access the fallback theme. Which platform plugin gets
loaded depends on the environment. Our platform plugin
returns a KIconEngine, which I'm guessing has a
reasonable default for Plasma.
I think there are other platform plugins for other
prominent workspace environments.
I don't know how the "ultimate fallback" works when
there's no suitable plugin. I think the fd.o spec pro-
scribes the hicolor theme then? In that case it would
be up to the distro to make sure this works out.
I'm not sure what alternatives we have here. It's not
reasonable for KF5 to override the platform plugin re-
gardless of environment, and I don't think duplicating
the platform plugin system inside KIcon or writing a
wrapper around QIcon::fromTheme seems sensible.
Cheers,
Albert
Cheers,
Eike
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
