For the list's benefit, here's a log of a technical discussion
we had in #kde-devel as an extension of this thread that went
over various aspects of the problem and possible solutions (I've
removed some unrelated parts):
[23:33] <tosky> uhm, I have no idea of how it works in details, but I
understood it's about missing icon if you use a normal KF5 application
outside Plasma
[23:35] <hein> tosky: and solving that by adding an API to KF5 that
overrides the spec fallback with a random other icon theme that isn't a
dependency of KF5 seems like a layering violation to me
[23:35] <hein> tosky: it also means KF5 apps would behave differently
from Qt apps, which wasn't the goal
[23:36] <tosky> hein: are you saying that setting those icons as part of
the hicolor theme should solve the problem?
[23:37] <hein> tosky: no, that's what the fd.o spec says
[23:37] <hein> tosky: which is what KF5 targets
[23:38] <hein> tosky: having a
fetchIconFromWellKnownThemeThatMayOrMayNotBeInstalled() API doesn't seem
like a solution to me
[23:40] <hein> tosky: if an app really really wants some sort of private
overlay they could also use QIcon::setThemeSearchPaths and
QIcon::setThemeName
[23:40] <tsdgeos> better than fetchIconFromThemeThatIsNotATheme
[23:40] <tsdgeos> at least if you're lucky you'll get an icon :D
[23:43] <tsdgeos> hein: apachelogger actually said that yes, he is ok
with the regression, and i actually am not sure i disagree with it
[...]
[23:46] <apachelogger> FWIW as I noted, I think windows and osx is the
bigger question mark
[23:46] <hein> apachelogger: I think I vaguely vaguely vaguely remember
Pov talking about this re KF5 on Windows
[23:46] <apachelogger> in particular since the docs say terrible things
about fromTheme -> Note: By default, only X11 will support themed icons.
In order to use themed icons on Mac and Windows, you will have to bundle
a compliant theme in one of your themeSearchPaths() and set the
appropriate themeName().
[23:46] <hein> apachelogger: I think their copy of Qt hardcodes the KDE
platform plugin
[23:46] <hein> or something like that
[23:47] <apachelogger> sounds scary xD
[23:47] <hein> but I still think that this stuff needs to happen on the
Qt level instead of saying "KF5 apps should use a different API and
behave differently from Qt apps again" is the right fix
[23:50] <apachelogger> *nod*
[23:51] <jpwhiting> hein: that may be, but what should such an api at
the Qt level look like ?
[23:51] <hein> it could be as easy as adding a QIcon::setFallbackThemeName
[23:51] <jpwhiting> which probably wont work on win/osx, right ?
[23:51] <hein> or a list of fallback theme names
[23:51] <jpwhiting> since they don't use icon themes, etc.
[23:51] <jpwhiting> or do they
[23:51] <hein> this sounds horrible, but is effectively what tsdgeos
wants if i understand him right
[23:51] <jpwhiting> but QIcon::fromTheme doesn't recognize/work with those
[23:51] <hein> tsdgeos' stance comes down to "I'm the app dev and i know
these icons i want are only in oxygen"
[23:51] <hein> which is implicitly a per-app thing
[23:52] <jpwhiting> yep
[23:52] <jpwhiting> hein: the porting guide for porting applications to
android/etc. suggests including all assets like that inside a qrc, I
wonder if we should adopt that practice on desktop also
[23:53] <jpwhiting> the drawback to that approach is that the assets
can't be shared between different applications
[23:53] <jpwhiting> i.e. the flags kgeography uses/ships can't be used
in other places that also want to display flags, etc.
[23:53] <hein> jpwhiting: that's what i meant with the "private overlay
thing" earlier and setThemeSearchPaths/setThemeName
[23:54] <hein> jpwhiting: the problem with using setThemeName is that
then you override the QPA mechanism
[23:54] <frinring> also means that one needs to know all icons/resources
that the used (framework) libs use
[23:54] <hein> jpwhiting: so semantically it would need to be a
setFallbackThemeName that just adds one more thing between QPA + hicolor
or sth
[23:54] <tsdgeos> note i'm not speaking about any app specific icon
[23:54] <tsdgeos> have a look at the strace
[23:54] <tsdgeos> it's document-open
[23:54] <hein> jpwhiting: which is effectively what KIcon does
[23:54] <tsdgeos> and those things
[23:54] <tsdgeos> hicolor is not a theme and is not supposed to be
[23:54] <tsdgeos> i guess it's just that linux sucks
[23:54] <hein> tsdgeos: in what DE?
[23:54] <tsdgeos> and what i want can't be solved
[23:55] <hein> unity? why does unity not install a QPA plugin if it's
using Qt anyway?
[23:55] <apachelogger> hein: an intermediate fallback might be cheating
[23:55] <tsdgeos> hein: what does it matter which DE it is?
[23:55] <tsdgeos> hein: unity is not using Qt yet
[23:55] <hein> tsdgeos: because Qt's platform abstraction mechanism cares
[23:55] <hein> what DE it is
[23:55] <jpwhiting> yeah, it shouldn't matter which DE we are using to
run our application
[23:55] <hein> jpwhiting: then convince Qt of that
[23:55] <hein> QPA plugins is the integration mechanism it provides to ISVs
[23:55] <jpwhiting> well, Qt wants to "look right" on every platform
[23:56] <jpwhiting> look native, etc.
[23:56] <hein> jpwhiting: platforms also want Qt to look right on them
[23:56] <jpwhiting> yep
[23:56] <tsdgeos> hein: probably that's the culprit, does linux has not
a DE abstract way of setting the default icon theme?
[23:56] <jpwhiting> so the "correct" solution is install an icon for
every theme/qpa possible ?
[23:56] <hein> i'm not going to say "platforms who don't care lose", of
course, i realize that's not a solution
[23:56] <hein> but it's basically how Qt works right now
[23:57] <jpwhiting> i.e. ship gtk/assuan whatever they call it icons
with kde applications so they will look native when running there, etc.
[23:57] <hein> if we want Qt to work differently we need to change Qt
[23:57] <jpwhiting> and windows icons and mac icons on those platforms
[23:57] <hein> tsdgeos: i guess we indeed don't @ de-abstract way to set
a fallback theme
[23:57] <hein> tsdgeos: maybe we need one indeed
[23:58] <apachelogger> mhmh
[23:58] <hein> tsdgeos: i don't know if icon theme inheritance solves this
[23:58] <tsdgeos> so basically if i run an app in plain X
[23:58] <hein> can hicolor inherit from something else?
[23:58] <apachelogger> hein: qt doesn't load frameworksplugin in !plasma
envrionments?
[23:58] <tsdgeos> I won't ever have icons
[23:58] <apachelogger> hein: no
[23:58] <tsdgeos> hein: no, hicolor is defined to be the base theme
[23:58] <apachelogger> would do lookup looping
[23:59] <hein> apachelogger: i'm not 100% sure how it works, I'm
*guessing* it's something like "hey plugin ... do you want to do shit
here?" and the plugin looks and says "KDE_FULL_SESSION ain't true, nop
nop nop"
[23:59] <apachelogger> a spec implementation may add inherit fallbacks
before hicolor (which is what we do in teh platform plugin essentially)
[23:59] <hein> apachelogger: it's environment driven but i don't know
the details of the negotiation
[23:59] <apachelogger> hein: well if the plugin doesn't want to do
things then I think the problem is on our end
[23:59] <hein> i thought maybe "make hicolor inherit" was the "system
config" hack
[23:59] <hein> apachelogger: no
[00:00] <hein> apachelogger: loading our plugin outside plasma would be
broken
[00:00] <hein> apachelogger: our plugin does things like load kde
settings and make qt use kde dialogs
[00:00] <hein> apachelogger: which you don't want in gnome
[00:00] <apachelogger> ah yes
[00:00] <apachelogger> well
[00:00] <apachelogger> this is a shit problem
[00:00] <jpwhiting> indeed
[00:00] <apachelogger> perhaps intermediate fallback setting is indeed
the way to go
[00:01] <hein> i can see two things, either there's a
QIcon::setFallbackThemeName which makes it a per-app issue, or the icon
spec gets a way to set a system default overriding hicolor
[00:01] <frinring> what about other qt-based DEs? is the
framework-platform adapter really plasma workspace only? why exactly
perhaps?
[00:01] <apachelogger> of course having every app set the fallback
manually is crap as well
[00:01] <hein> the problem with the latter is that distros don't pick
oxygen then
[00:01] <hein> apachelogger: but it's in some sense what it comes down to
[00:01] <apachelogger> in particular consider one may set breeze and the
other may set oxygen and the other may set some other thing
[00:01] <frinring> (and why is it part of frameworks actually, and not
plasma workspaces then?
[00:01] <hein> apachelogger: the app dev knows "these icons i want ...
they're mostly in oxygen", which may not be true for any other app
[00:02] <hein> apachelogger: it's in some sense coincidental that kde
has a lot of app devs coming up with the same answer to that
[00:02] <apachelogger> hein: yes, I agree
[00:02] <apachelogger> I do not agree with having each app set it
manually though
[00:02] <apachelogger> maybe have kaboutdata do it or something
[00:02] <hein> apachelogger: and qt has no other mechanism to share
behavior across apps in an extensible way other than the platform plugin
[00:02] * frinring learns to better address people
[00:02] <apachelogger> otherwise you can probably kiss platform
continuity goodbye xD
[00:03] <apachelogger> actually that's also rubbish.... the manually set
fallback would have to be before the QPA, so we then have no means to
enforce a platform wide theme anymore I guess
[00:03] <hein> apachelogger: but would every user of kaboutdata be happy
with kaboutdata splicing in oxygen? etc. ...
[00:03] <frinring> hein: you said "loading our plugin outside plasma
would be broken". what about other qt-based DEs? is the
framework-platform adapter really plasma workspace only? why exactly
perhaps?
[00:03] <hein> frinring: other qt-based DEs would provide their own plugin
[00:03] <hein> frinring: that they're also qt-based doesn't mean they
share anything with plasma
[00:03] <frinring> hein: so why is it part of frameworks actually, and
not plasma workspaces then?
[00:04] <apachelogger> hein: they can simply override whatever aboutdata
set?
[00:04] <hein> frinring: that's a good question i don't know the answer to
[00:04] <hein> apachelogger: right
[00:04] <apachelogger> frinring: we've been wondering that a while ago
[00:04] <apachelogger> no one knew really :P
[00:04] <hein> apachelogger: but that's sorta like turning KAboutData
into KApplication :)
[00:04] <apachelogger> yeah
[00:04] <hein> you still have a "KF5 is no longer a Qt app now" then
[00:04] <hein> in some sense
[00:04] <apachelogger> except that is kind of what is needed ;)
[00:05] <apachelogger> hein: maybe the QPA lookup could be made smarter
though
[00:05] <hein> apachelogger: i was thinking about QPA inheritance a
while back ;)
[00:05] <hein> yay complexity
[00:06] <apachelogger> it possibly could be as simple as having plugins
go "I might have to offer something in this envrionment, unless
something else knows they do"
Cheers,
Eike
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
