
You need to right-click tray icon very often. No effect. If it worked once, then it seems more likely to work again… (🤔sounds strange, I know)
Client version:
2.4.1
Operating system:
Kubuntu 18.04
OS language:
EN
Qt version used by client package (Linux only, see also Settings dialog):
5.6.2
Client package (From ownCloud or distro) (Linux only):
From ownCloud
Installation path of client:
???
@michaelstingl Do you have a machine to reproduce this? If yes try the 2.5.0 nightlies with newer Qt?
"Works for me" is all i can say. (But i'm using Qt 5.10.1 on Archlinux)
This looks like a Qt or Plasma bug.
Same with 2.5.0 daily with Qt 5.10.1

I run a VirtualBox machine fresh installed from kubuntu-18.04-desktop-amd64.iso (no special options, everything default)
BTW Why does the "Close" button has the "X"?
I'm also on kubuntu 18.04 but haven't seen this issue. I was using my own builds with a different Qt version though. I'll see - at best we can find yet another tray icon workaround though. :/
I can reproduce with the kubuntu-18.04 iso. Interestingly floating systray widgets work (on the second click, it seems focus needs to go to the tray first - that's not the case for other indicators), but systrays in panels don't do right-clicks reliably at all. Left-clicks work every time.
I tested with 2.4.1 (built with and running with Qt 5.6.2)
And I can confirm that my manually built version with Qt 5.9.1 using the system Qt 5.9.5 works as expected. And with the nightly using 5.10.1 it doesn't work again.
(also note that my custom build is the only instance to use the ubuntu monochome icon (black cloud with white outline, I didn't find it in our repo, where does it come from?), the others use the default colored owncloud icon)
It seems to relate to some of our other tray workarounds - with OWNCLOUD_MINIMAL_TRAY_MENU=1 it works. Sadly, OWNCLOUD_FORCE_QDBUS_TRAY_WORKAROUND=1 makes it work too.
@ogoffart I currently have no good guess as to why my 5.9 version would work when the 5.6 and 5.10 versions don't. Any ideas?
I don't want to enable the workaround we built for qdbusmenu because that triggered another set of tray bugs. :/
Maybe because of a plugin that is only loaded with system's Qt (such as the KDE integration plugin). It might have a different systray implementation.
Reminds me somehow to https://github.com/owncloud/client/issues/5968 (see also https://github.com/owncloud/enterprise/issues/2151)
Maybe because of a plugin that is only loaded with system's Qt (such as the KDE integration plugin).
https://unix.stackexchange.com/a/358500
https://unix.stackexchange.com/a/220110
In my opinion, we should not ship Qt for distribution that have a Qt that is recent enough.
So distribution with Qt >5.6.1 (or 5.9.1?) should simply use system Qt
They won't get HTTP2 then though
(but tray is more important than HTTP2 so @ogoffart is right)
adding @dschmidt to the discussion…
I've tried to verify that this is indeed about the platform plugins. Comparing the loaded libraries doesn't help unfortunately since both versions load things like /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so - though it could be that the distributed version discards it somehow. I haven't yet figured out how to tell what's actually happening with the tray.
What I could verify is that my self-build version also starts having a broken tray if I remove /usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so and that makes sense as this library contains kdeplatformsystemtrayicon.cpp
So: Yes, using the system Qt for the distributions where it's new enough to not cause other issues would be the correct solution.
I'll also look for workarounds (the minimal tray menu works, after all), but those will likely need compromises with respect to features, or introduce new issues down the line.
Some debugging has shown me that contextMenu->isVisible() always returns false if the kde integration plugin isn't loaded. And building the context menu in aboutToShow() doesn't work either, similar to OSX.
@michaelstingl here are linux packages built from ckamm' tray-workarounds branch. Can you try if this improves the situation on your kubuntu too. for me is seems to ease the pain.
https://download.owncloud.com/internal/repo/desktop:/testing/download/
I am unhappy with my test environment:
@jnweiger Odd. Are all of these tests done with binaries that link to a custom Qt version that has a different minor version number from the system Qt? The important bit is to ensure that KDEPlasmaPlatformTheme.so can't be loaded - otherwise it should just work.
gna my tests were faulty, I'll recheck and keep an eye on KDEPlasmaPlatformTheme.so -- thanks for raising doubt :-)
All of these done on one and the same VM in that order, with purge and autoremove in between and ca. 240 online updates waiting to be installed.
All done linked with our own QT, either 5.6.2 or 5.10.1, never with a system qt.
No dolphin, nemo, nautilus plugins installed.
grepped for KDEPlasmaPlatfomTheme in ldd and lsof output using grep -i pla.
There are matches only for things like
.../libcomposeplatforminputcontextplugin.so
.../platforms/libqxcb.so
.../plasmashellVr1298.4.slave-socket
Reproduced the same behaviour after installing all pending ubuntu online updates.
@ckamm, I now officially love your trayworkarounds branch!
@ckamm, what would be the effort to backport this PR for 2.4.2 ?
@jnweiger Thanks for the elaborate testing! The patch applies cleanly to 2.4, would be no effort to backport.
Great! Also for 2.4.* with Qt-5.6.2 ?
@jnweiger Backport PR is https://github.com/owncloud/client/pull/6594
I don't understand the question about 2.4.* with Qt-5.6.2. A bugfix would only go into 2.4.2? And hopefully the Qt version doesn't matter - it might though! Could I ask you to test the 2.4 builds as thoroughly? I'd be sad if we broke trays for 2.4.2 instead of improving the situation.
building test packages...
I was afraid Qt-5.6.2 might need other workarounds than 5.10.1 - if not, the better!
Thumbs up for the backported PR! Approved from my side, but please doublecheck Olivier's comment.
@jnweiger @ogoffart close now?
Backport test done:
Install 242rc1 both testpilotcloud-client and owncloud-client on a ubuntu 18.04 plasma VM.
wget -nv https://download.opensuse.org/repositories/isv:ownCloud:desktop:client-2.4.2rc1/Ubuntu_18.04/Release.key -O Release.key
sudo apt-key add - < Release.key
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop:/client-2.4.2rc1/Ubuntu_18.04/ /' > /etc/apt/sources.list.d/isv:ownCloud:desktop:client-2.4.2rc1.list"
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/testpilot:/testing/Ubuntu_18.04/ /' > /etc/apt/sources.list.d/isv:ownCloud:testpilot:testing.list"
sudo apt-get update
sudo apt purge -y owncloud-client libowncloudsync0
sudo apt purge -y testpilotcloud-client libtestpilotcloudsync0
sudo apt-get install -y owncloud-client
sudo apt-get install -y testpilotcloud-client
owncloudcmd --version
testpilotcloudcmd --version
zypper addrepo https://download.opensuse.org/repositories/isv:ownCloud:desktop:client-2.4.2rc1/openSUSE_Leap_42.2/isv:ownCloud:desktop:client-2.4.2rc1.repo
zypper addrepo https://download.opensuse.org/repositories/isv:ownCloud:testpilot:testing/openSUSE_Leap_42.2/isv:ownCloud:testpilot:testing.repo
zypper refresh
zypper rm -y owncloud-client libowncloudsync0
zypper rm -y testpilotcloud-client libtestpilotcloudsync0
zypper install -y owncloud-client
zypper install -y testpilotcloud-client
owncloudcmd --version
testpilotcloudcmd --version
Both systems
Backport test done:
#### Task Install 242rc1 both testpilotcloud-client and owncloud-client on a ubuntu 18.04 plasma VM. ##### ubuntu wget -nv https://download.opensuse.org/repositories/isv:ownCloud:desktop:client-2.4.2rc1/Ubuntu_18.04/Release.key -O Release.key sudo apt-key add - < Release.key sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop:/client-2.4.2rc1/Ubuntu_18.04/ /' > /etc/apt/sources.list.d/isv:ownCloud:desktop:client-2.4.2rc1.list" sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/testpilot:/testing/Ubuntu_18.04/ /' > /etc/apt/sources.list.d/isv:ownCloud:testpilot:testing.list" sudo apt-get update sudo apt purge -y owncloud-client libowncloudsync0 sudo apt purge -y testpilotcloud-client libtestpilotcloudsync0 sudo apt-get install -y owncloud-client sudo apt-get install -y testpilotcloud-client owncloudcmd --version testpilotcloudcmd --version ##### leap zypper addrepo https://download.opensuse.org/repositories/isv:ownCloud:desktop:client-2.4.2rc1/openSUSE_Leap_42.2/isv:ownCloud:desktop:client-2.4.2rc1.repo zypper addrepo https://download.opensuse.org/repositories/isv:ownCloud:testpilot:testing/openSUSE_Leap_42.2/isv:ownCloud:testpilot:testing.repo zypper refresh zypper rm -y owncloud-client libowncloudsync0 zypper rm -y testpilotcloud-client libtestpilotcloudsync0 zypper install -y owncloud-client zypper install -y testpilotcloud-client owncloudcmd --version testpilotcloudcmd --version Both systems * log in on the desktop * left click the system menue: a dialog opens containing plasma search. * run the installatin procedures above. the correct cliebt version numbers are printed at the end. Both systems, both clients: * right click the tray icon multople times. a dialog containing quit opens and closes * left click the icon, the settings window opens. * use right click -> quit to end the client.
Success. Thank you all.Closing.
Most helpful comment
In my opinion, we should not ship Qt for distribution that have a Qt that is recent enough.
So distribution with Qt >5.6.1 (or 5.9.1?) should simply use system Qt