after the recent upgrade to KF5, I have found that the new version of kmail (kde-apps/kmail-17.04.3:5) is unable to display icons which severely breaks usability I have found this mentioned here: https://archives.gentoo.org/gentoo-user/message/c9d4c240084a23ecb82ba1d734e7153c but without solution please tell me what information would help to debug this; I doubt that 'emerge --info' or so would be of any use here ... what might be of interest is that my workflow is to run kmail remotely over xpra from terminal, not from KDE session - this is what I have common with Mick who says he uses Enlightenment, i.e. he also doesn't run it from KDE session
digging into this further, I have found that setting QT_QPA_PLATFORMTHEME helps - in my case, I've used `export QT_QPA_PLATFORMTHEME=lxqt` before running kmail this value seems to be set when I log in via graphical login manager (sddm) but empty otherwise now it looks to me broken by design ... how is that the old version worked just fine in my setup and the new one has this problem? is that too much these days to expect things to work out of the box, without having to google and set your own workarounds (which you'll probably forget by the time the next major version is released, so it may cause unexpected breakages in that future new version which would be impossible to debug for an ordinary user ...)? p.s. for others affected coming here: there is an utility that allows to configure graphical theme for Qt called `qt5ct`, independently on your desktop environment (you even don't have to have any DE), which sets its own theme, so you have to run the applications (and this utility) with 'QT_QPA_PLATFORMTHEME=qt5ct'
There's not much we can do here I'm afraid. If you don't use a desktop environment that provides a platformtheme for Qt you have to set it up yourself, as you describe.
well, I can imagine that ... if (all) Qt apps need this, let's add the variable to /etc/env.d on Qt install, the same as e.g. XDG_DATA_DIRS in 30xdg-data-local/90xdg-data-base; login via graphical manager would then override the value OR if it is used via some function, let's patch it (and propose the change upstream) for example, I see messages like: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-kavol' so why not something like: QSomeFunction: QT_QPA_PLATFORMTHEME not set, defaulting to 'qt-plain' ? imagine you buy a new car, and you have to turn on the radio (because everyone listens to the radio, right?) to be able to open the windows, otherwise if you don't want to play radio, then you have to google (it's not written in user manual) and find out that you have to crawl under the car to connect some jumper to be able to open windows without having the radio on sounds insane? how is that similar things in software are considered perfectly okay? I mean - nothing personal here, I understand this comes from upstream - this really shouldn't be thrown on user; obviously, as the link I have provided shows, it is not just my problem, and there are more other cases (by other I don't mean other people but other configurations that exhibit the problem), so it should be solved at one place instead of telling everyone to write own config hack so please consider the above proposals, or anything better you can come up with; unfortunately, my knowledge is too limited to write a patch myself :-(
I agree, it is insane. The last time that I saw this brought up upstream, the answer was that every environment is expected to provide their own QPA plugin for everything to work properly. That sounds nice in theory, but in practice of course it will never work. Instead (last time I checked), it just tries to use the active icon theme or fall back to hicolor, so in the case of many KDE applications which have custom icons the user just gets no icon instead. We've thought about downstream solutions but I'm really not sure if it's a good idea to try globally overriding QT_QPA_PLATFORMTHEME and friends.
Let's use one single bug for this topic. *** This bug has been marked as a duplicate of bug 564838 ***
(In reply to Andreas Sturmlechner from comment #5) > Let's use one single bug for this topic. > > *** This bug has been marked as a duplicate of bug 564838 *** ahem, sure it is the same topic? as I understand it, that one is about icons not being available, this one is about icons not being used ...?
It is exactly the same.
ok, I take your word :-) thanks for working on this honestly ... my own bugzilla backlog is just growing and growing :-/
