Desktop: No way to access account management on GNOME on Ubuntu

[juliushaertl]

The new tray menu doesn't register a menu anymore so current Ubuntu releases and GNOME in general will fail. The extension ubuntu uses to bring back status indicators into GNOME only displays status icons if a MenuBar is provided in the StatusNotifierItem.

https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/aadd60bb9dbda093478d763cecf6128cb5e9fd2c/appIndicator.js#L174
https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/aadd60bb9dbda093478d763cecf6128cb5e9fd2c/appIndicator.js#L100-L101

While this is more an issue of the GNOME environment itself, this actually causes the new tray menu to be unreachable and therefore also no new accounts can be setup. The button to manage accounts has been moved to the new tray menu.

@misch7 @DominiqueFuchs Maybe we should at least make sure that if the application is opened a second time we trigger the new tray menu instead of the settings dialog that is currently opened.

[juliushaertl]

I could indeed make the status icon on gnome work again with the following patch, that forces to add an empty menu. However this was the issue that it requires double clicking the indicator icon to open the nextcloud ui and is probably causing issues on other environments, so I'll have another look if we can provide an upstream fix for the gnome extension.

diff --git a/src/gui/owncloudgui.cpp b/src/gui/owncloudgui.cpp
index d271059ab..04c1ab70c 100644
--- a/src/gui/owncloudgui.cpp
+++ b/src/gui/owncloudgui.cpp
@@ -58,6 +58,7 @@ const char propertyAccountC[] = "oc_account";
 ownCloudGui::ownCloudGui(Application *parent)
     : QObject(parent)
     , _tray(nullptr)
+    , _menu(new QMenu(nullptr))
     , _settingsDialog(new SettingsDialog(this))
     , _logBrowser(nullptr)
 #ifdef WITH_LIBCLOUDPROVIDERS
@@ -67,9 +68,9 @@ ownCloudGui::ownCloudGui(Application *parent)
 {
     _tray = Systray::instance();
     _tray->setParent(this);
+    _tray->setContextMenu(_menu);
     // for the beginning, set the offline icon until the account was verified
     _tray->setIcon(Theme::instance()->folderOfflineIcon(/*systray?*/ true));
-
     _tray->show();

     connect(_tray.data(), &QSystemTrayIcon::activated,
diff --git a/src/gui/owncloudgui.h b/src/gui/owncloudgui.h
index 928a0fbd0..67d6dc75f 100644
--- a/src/gui/owncloudgui.h
+++ b/src/gui/owncloudgui.h
@@ -115,6 +115,7 @@ private:
     void setPauseOnAllFoldersHelper(bool pause);

     QPointer<Systray> _tray;
+    QPointer<QMenu> _menu;
     QPointer<SettingsDialog> _settingsDialog;
     QPointer<LogBrowser> _logBrowser;

[rullzer]

Can't we just add back the right click menu?
I mean I also find it confusing I have to take taht many steps to close the application. Or to rach the settings if I want to.

[juliushaertl]

That depends a bit on how the environments handle click and rightclick on the systray. The gnome extensions shows the menu on both click options. But yeah, it would actually be nice to check if it is possible to have the rightclick still open the menu as before. :+1:

[mithodin]

I think this is also the reason why I can't open the settings from the status icon in i3 anymore. The client is running, I can open the settings by running the client again from the shell, but clicking the status icon does nothing.

[Fiech]

Ahh... I have the same problem under KDE. I thought I was going crazy, especially, because no way of logging or stracing produced something that would explain this behaviour. Would be great, if we could get back the right-click functionality.

[NESC1US]

excuse my question, but how does one right-click on a touchscreen?

[HHGAG]

Long tap =)

Back to topic, this issue causes under KDE a huge .xsession-errors file, which could lead to exhausting free space, freezes on some systems, etc. see
https://github.com/nextcloud/desktop/issues/1818

[er-vin]

@jancborchardt what do you think? we bring back the context menu as @rullzer and @juliushaertl propose? I admit I miss it, the new approach forces me more clicks than before for some actions.

[jancborchardt]

@er-vin ideally we show the new systray menu both on left- and right-click of the tray icon. But I’m not sure this is the core of the issue, as this is about the new systray menu not being accessible in the first place.

Maybe we should at least make sure that if the application is opened a second time we trigger the new tray menu instead of the settings dialog that is currently opened.

How about actually when you open the app, that the systray dialog is opened as the primary thing? The advanced settings can easily be accessed through there, and the core functions are already available. A "second time opening" would be not understandable.

[er-vin]

Honestly, bringing back a context menu is a much easier fix on those platforms. Indeed, from the description and code of @juliushaertl shell extension shipped by default on Ubuntu and window managers like i3, if you don't have a context menu registered you basically get no systray icon or a systray icon you can't interact with.

Also I'd argue it is less disruptive to the existing users workflow who got used to the context menu. Beside I'm yet to encounter a user who don't expect a menu on right clicking an icon (whatever the platform). It's really a pervasive interaction.

[juliushaertl]

How about actually when you open the app, that the systray dialog is opened as the primary thing? The advanced settings can easily be accessed through there, and the core functions are already available. A "second time opening" would be not understandable.

That would actually be a good idea for vanilla GNOME without a systray. For the regular use case I agree with @er-vin that the context menu still has its benefits, for quickly going to the settings or pausing the sync/closing the nextcloud app.

[er-vin]

Note I'm not even sure how to figure out we're in the "vanilla GNOME without a systray" case. I know how to detect a GNOME Shell session just fine... but to know if it has one of those systray extensions or not... no idea.

[jancborchardt]

Sorry but I have to step in and say that there should not be a difference between left-click and right-click, this will be confusing. We designed the new tray menu to specifically replace the right-click menu and also to show the most important parts of the "settings" dialog, so we should do that.

Lots of people don’t know that right-click menus exist for a specific thing, or right-click by mistake instead of left-click (especially on touchpad) so we should make things as simple as possible.

• Left-click on the systray icon → new tray menu
• Right-click on the systray icon → new tray menu
• Opening the app via programs → new tray menu
• Want to go to the settings? → go to "Settings" in the menu of the tray menu, which itself can be accessed any way people want.

[er-vin]

Could we at least stop calling it a "menu", because it doesn't look or behave like a menu at all. It's not to be annoying about it but that keeps confusing me in discussions across versions.

But OK, so no context menu on the systray (although I obviously disagree on the assumptions stated here regarding awareness of context menus in the desktop client user base).

Now to address that one I'll roll a PR doing the following:

• add the missing dialog popup on right click (right now it doesn't do anything on right click);
• open the new dialog instead of the settings dialog when the application is launched as it was already running.

That will boils down to the "Maybe we should at least make sure that if the application is opened a second time we trigger the new tray menu instead of the settings dialog that is currently opened." solution that @juliushaertl was proposing in the beginning.

I don't think we can do any better than that because of the "vanilla GNOME Shell" detection problem I was mentioning previously. But at least that dialog will be reachable even in the systray less GNOME Shells.

Is it OK as a compromise?

Of course, if anyone has a reliable approach to know if a GNOME Shell session has a systray I'm all ears. But please no heuristics that are doomed to regularly break.

[er-vin]

OK... so it turns out we won't even be able to have the right click working reliably on Linux. We just don't get the event on KDE Plasma and GNOME Shell + extension. I found a horrible hack (don't ask) which makes it work properly on Plasma but it behaves oddly on GNOME Shell (as in the shell decides to popup an empty context menu anyway and the window can never hide on right click...).

This won't work properly on those platforms without changes in their systray hosting. Please advise on how best to move forward on this.

[jancborchardt]

Could we at least stop calling it a "menu", because it doesn't look or behave like a menu at all. It's not to be annoying about it but that keeps confusing me in discussions across versions.

You’re right – let’s call it "the app" (EDIT: or "main dialog" as it seems from the code). ;) Cause that’s what it aims to be, the main part of the app. The current "settings" dialog should move further in the background as we make the app more and more useful. And the only other visible components should be the sharing dialog and the account setup (where the latter is sort of extension of the app).

although I obviously disagree on the assumptions stated here regarding awareness of context menus in the desktop client user base

The thing is that we have to look beyond our current desktop client user base to make Nextcloud accessible to a broader audience. Yes people here on Github know technology and use computers most likely every day, but doing usability tests it really is eye-opening how difficult software is, and we don’t even notice it anymore. So we have to keep it simple first and foremost.

open the new dialog instead of the settings dialog when the application is launched as it was already running.

Sounds great!

This won't work properly on those platforms without changes in their systray hosting. Please advise on how best to move forward on this.

Not having right-click on those platforms is fine then. As long as the left-click opens the app, and right-click doesn’t do anything else like another menu.

Thank you! :)

[er-vin]

Alright so that should be what #2099 does, right-click is not doing anything on those platforms. This issue will thus be closed when the PR is merged.

And yes I ended up using "main dialog". After all from my perspective in the code it's all "the app". ;-)