Desktop: Unable to access gui on GNOME 3.26.2

[rickvanderzwet]

Status icons are removed in GNOME starting from 3.26.x making it impossible to access the gui by clicking on the status icon.

The workaround I use to get access to the GUI is killing the active nextcloud process and starting one interactively:

$ killall nextcloud
$ nextcloud &

I using using:

$ nextcloud --version
Nextcloud version 2.3.3
Git revision 57bc7918d7b0650c116f3512787f7677d4e5ab17
Using Qt 5.9.4, built against Qt 5.9.1
Using 'OpenSSL 1.1.0g-fips  2 Nov 2017

A more intuitive way to start the nextcloud gui would be preferred.

[rmader]

With gnome-shell 3.28, the discontinued TopIcon Plus addon, which used to be a great workaround for this, starts to get buggy. So this is becoming very urgent, IMO.

Also, I'd say this is not an enhancement but actually a bug, since gnome-shell is THE major DE again.

[hbeezim]

:+1:
I confirm the behaviour with TopIcon Plus addon on gnome-shell 3.28.

[jmml97]

Yup, this is a major issue on gnome-shell 3.28. It doesn't work with TopIcon Plus.

[qoheniac]

This has also been reported here.

[bbkz]

I am also hit by this missing feature.

My experience is that i have to use Xorg instead of Xwayland to get the TopIcon addon working with the nextcloud-client, some of my other apps work.

But this really is a "killer" feature, if your only way to verify that the program is running, would be like

ps aux | grep nextcloud

and then checking the state of the synchronization, with

tail -f .owncloudsync.log

some user (not me) could stop using it.

[rmader]

Would it be possible to use StatusNotifierItem or AppIndicator instead of the classic systray? Then it would work with https://extensions.gnome.org/extension/615/appindicator-support/, which seems to be maintained by Canonical and installed by default in ubuntu (AFAIK).

[bbkz]

For me this would not change a lot, as i am using Fedora and this gnome extension is not working for me.

So the result would be the same, it would depend on a external extension, which may work in your distribution (eg. setup) or not.

I don't know what would be a "do-able" solution (maybe not using gnome anymore :-D). Having a gnome extension delivered with the nextcloud client, would be very nice.

[rmader]

What do you mean by "not working"? First of all the application has to support one of the formats as it does not support classic systray. I'm using fedora, too, and some application like steam do so.

Further on, we could ask fedora to provide a packaged version and make the nextcloud-client package recommend it.

[bbkz]

What do you mean by "not working"?

A thank's now i get it, i just didn't had a application running which is using this feature.

Of course i would also be happy if this would be choosen as a solution to address this problem. Can you explain me why you prefer the integration you mentioned. (just because i am interested..)

[rmader]

Well, you mean using StatusNotifierItem instead of creating and maintaining a gnome extension? Because using StatusNotifierItem is probably much less work for the developers.

Maybe nextcould already supports it (probably at build time) and all we need to do is to ask the maintainers to change the build options. Or the nextcloud-devs to change the default ones. Or, as this post implies, it's a QT-thing and we should ask the fedora maintainers to ship QT with SNI support.

[bbkz]

Thank you, this explains a lot.

[rmader]

Ok, dicking a bit deeper, there is a package for QT4 called sni-qt, which is supposed to turn all legacy qt status-icons into using StatusNotifierItem. It's even installed by default on fedora (atleast on my system it was already pulled in as dependency from somewhere).
As outlined here, applications build with QT 5.4 and higher (the current nextcloud client on fedora is build against QT 5.10) should not need any modifications. I therefore conclude that there is a bug in how QT is configured in fedora, as the nextcloud-client and other QT apps clearly do use the legacy api (I'll make a ticket, soon)

If that's fixed it should make the appindicator-support extension work again, solving the issue here.

I don't think we can expect the nextcloud-client devs to follow gnomes very specific design ideas how things should work. I interpret them as basically saying: apps like nextcloud-client should not exist. The maximum the devs could do would make an option to exchange the tray icon with minimization, like some similar applications like the mattermost client do.

P.S.: creating a gnome extensions seems be an anti goal from gnomes perspective. They removed the status icon support for exactly the purpose of clearing the UI.

[rmader]

For all Fedora users here: I just opened a ticket for this https://bugzilla.redhat.com/show_bug.cgi?id=1607147

[rmader]

For Fedora users: the QT maintainers seem to have figured out a bug
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a5657e9770
https://bugzilla.redhat.com/show_bug.cgi?id=1601033

So with the appindicator-support extension, which is maintained from canonical and therefore hopefully more future proof that TopIcon Plus, things should work again soon.

[DudleyDursley]

I don't think we can expect the nextcloud-client devs to follow gnomes very specific design ideas how things should work. I interpret them as basically saying: apps like nextcloud-client should not exist. The maximum the devs could do would make an option to exchange the tray icon with minimization, like some similar applications like the mattermost client do. - @treba123

That's the only viable option though. You can't depend on people installing GNOME extensions. The client has to reopen when you click on the normal launcher icon without manually killing the process first.

[favadi]

Should we change the behaviour of nextcloud desktop so that it reappears if it is already running in background?

[qoheniac]

Yes, please!

[shtrom]

FWIW, if you hit the Activities menu, shove your mouse pointer in the top-left corner, or hit the Super key, you'll get an exposé like mode, with your favourite applications in a dock-like widget, and a search bar.

I just type nextcloud in that search bar to bring the running application back to the foreground.

[rmader]

@shtrom sorry but you're missing the point here. It's not about people not knowing gnome. It's about closing the nextcloud window. Then nextcloud still runs in the background and you can't reopen the window (without killing nextcloud first).

[qoheniac]

@shtrom This will do the same as running nextcloud from the command line.

$> cat "$(locate nextcloud.desktop)" | grep Exec
Exec=nextcloud

For me this does nothing. The Nextcloud client just keeps running in the background.

$> nextcloud --version
Nextcloud version 2.3.3
Git revision 57bc7918d7b0650c116f3512787f7677d4e5ab17
Using Qt 5.10.1, built against Qt 5.9.1
Using 'OpenSSL 1.1.0h-fips  27 Mar 2018'
$> gnome-shell --version
GNOME Shell 3.28.3

[shtrom]

While I agree it's a UI issue (probably more to do with Gnome than Nextcloud), the point is, re-running nextcloud (from Gnome, the shell, or wherever that share the user session), when it is already running, will bring the window back up, rather than starting a new process.

[qoheniac]

No it doesn't. That's exactly what this issue is about.

$> pgrep nextcloud
2321
$> time nextcloud

real    0m5.420s
user    0m0.289s
sys 0m0.072s
$> pgrep nextcloud
2321

You are right in that no new process is started, but it doesn't bring the window back up either.

[shtrom]

:thinking: it does for me. That's Gnome 3.28.2 on Wayland with the AppImage version of Nextcloud [2.5.0daily (build 20180701)]

[rmader]

Hm, that's interesting. Can you try fedora/ubuntu repo versions? I'm on fedora 28. Just also checked the flatpak version from flathub, doesn't work for me either.

[DudleyDursley]

I'm also on Fedora 28 WS and the repo-version doesn't reappear. With the Flatpak from flathub on a Fedora Silverblue system it does. So I guess it depends on the distribution method or how these things are started/run.

[rmader]

@shtrom I can confirm it to work with the Appimage version (2.3.3). It should be noted, though, that there's now way from the gui to close the program, then. It only works via the tray-icon.

To fix that issue, I'd recommend to detect cases where no systray icon can be created, change the window exit behavior to minimize (gnome only has an exit button) and make right-click->quit on the dash symbol exit the program (instead of continuing to run in the background).

[shtrom]

(I'm on ArchLinux).

[rmader]

Browsing the code I found https://github.com/nextcloud/desktop/blob/b19abe9c86a3487474320abffe89f05140d10a1f/src/gui/main.cpp#L144-L170 which seems to already deal with the same problem on xfce.
There it displays an error popup, urging the user to install a systray. We could simply do that, too, on gnome with a slightly different text (linking to gnome-shell extension).

But I guess it would still be worth to fix the behavior without a trayicon to some extend (atm. the user would still have to kill nextcloud via commandline or some task manager)

[shtrom]

A popup telling me to install another piece of software would be an anti-feature for me. I think forcing the window to reliably reraise if no systray is found would be a more friction-less solution.

[qoheniac]

On top of the problem of having no GUI and no tray icon, the Nextcloud client starts to refuse to sync every now and then without producing any logs (I looked for messages in .owncloudsync.log and systemd's journal). There is a process running, but it does not sync. So as the GUI isn't working anyway, I took a look at the command line tool and voilà that works just fine. Here is the script I use to sync and store some of the information the tool provides:

#!/bin/bash

USER=XXX
PASSWORD=XXX
LOCAL_PATH=XXX
REMOTE_URL=XXX

FLAGS=(-h --non-interactive)
LOGFILE=XXX
EXCLUDE_INSTRUCTION="NONE,IGNORE"
EXCLUDE_CSYNC="walker,detect,ftw"

EXCLUDE_REGEX='\('"$(eval "echo INSTRUCTION_{$EXCLUDE_INSTRUCTION} csync_{$EXCLUDE_CSYNC}" | sed 's/ /\\)\\|\\(/g')"'\)'
if [ -z "$(pgrep nextcloudcmd)" ]
then
    date > "$LOGFILE"
    nextcloudcmd "${FLAGS[@]}" -u "$USER" -p "$PASSWORD" "$LOCAL_PATH" "$REMOTE_URL" 2>&1 | grep -v "$EXCLUDE_REGEX" >> "$LOGFILE"
fi

I also created a cron job that runs the script every 10 minutes. As this issue does not seem to get closed very soon, maybe we can use this discussion here to find the most convenient workaround.

[Blaimi]

seems to be a problem here:

https://github.com/nextcloud/desktop/blob/5ce9aedb7a887aa29ddd2b339b44c3bef0923e7b/src/gui/application.cpp#L399-L415

https://github.com/nextcloud/desktop/blob/84b7ed04e6b95de6050f5d6757b0d4385b297abb/src/gui/main.cpp#L121-L139

I don't know how to get any of the messages sent to the qCInfo Makro. As far as I investigated, they should appear in the logfile, but they don't.

[mcnesium]

Caution: this post is highly opinionated

The desktop client has never been a great piece of software. Being built on top of the Qt framework, it never integrates suitably into the native UX of pretty much any desktop (except you run KDE, I guess). On mac OS it doesn't even have a dock icon, while running in the foreground.

So the idea is: why not make this thing a background service? Since the UI is so broken, it runs kind of in the background anyways. Provide a decent config file (todays nextcloud.cfg is not really that), that can be pushed into everyones dotfiles-repo, and have the GUI tool be just an interface for it. Maybe this can also be done via Gnome Online Accounts or mac OS prefpane, I don't know what the Windows equivalent would be, but the basic point is: get rid of a GUI tool, that does a background job.

[NicolasGoeddel]

So the idea is: why not make this thing a background service?

That would be a wonderful idea. In our company we are also synchronizing data between an external nextcloud server and a local samba share using the nextcloud client. The problem is that I need to run a xorg session to run the nextcloud client. It would be much nicer when the client would actually be a simple terminal application.

[juliushaertl]

So I would consider this as fixed with 2.5.0. The current behaviour on gnome is:

• Running the nextcloud binary will open the settings

• The following GNOME extension will just keep offering a status notifier icon https://extensions.gnome.org/extension/615/appindicator-support/

• If your distribution ships gtk with libcloudproviders support and Nextcloud is compiled with it we offer integration into nautilus

[archont00]

• Since Gnome 3.3 the icon in systray is broken again - because AppIndicator does not work anymore https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/153
• libcloudproviders is not supported by Arch Linux (not sure why, there is no package even in AUR (user contributed) repository).

At least, running 'nexctloud' app opens the GUI again and the client continues to run in the background when window is closed.

[pawlowskatze]

For anyone experiencing this issue and coming here in the hope of finding a "fix", the following is my workaround:

_Note: I'm on fedora29 with x.org and topiconsplus and the problem is, that while the nextcloud client is actually running after being autostarted, there is no icon in the taskbar. Whereas, if I start the client manually after logging in (without autostart or after killing the autostarted instance), the icon is there._

After adding the nextcloud client to the startup programs via gnome-tweak-tool (or gnome-tweaks, or whatever it's called) I edit the associated .desktop file:

1. The file in question resides in the subdirectory .config/autostart of the users home directory.
   So, for example in a terminal session, enter cd ~/.config/autostart
2. Edit the nextcloud.desktop file by entering nano nextcloud.desktop
   _(replace nano by the name of the editor of your choice if required)_
3. In the file, change the line saying exec= so that the entire line becomes:
   Exec=bash -c 'sleep 5 && nextcloud'
4. Save the .desktop file - done.

What it does is simply waiting 5 seconds before launching the client. Your mileage may vary - perhaps you need to give it more time if your startup takes longer than mine.

Anyways, hope this helps someone
KR, Thomas

[ilippert]

re the workaround suggested by @pawlowskatze

My default nextcloud.desktop file in autostart included the line (f29, x-org)
X-GNOME-Autostart-Delay=3
how about simply increasing from 3 to 5 or 10?

anyway, this does not make the icon appear in my case.

interestingly, on wayland I get the icon, but clicking on it does not achieve anything.

[rmader]

interestingly, on wayland I get the icon, but clicking on it does not achieve anything.

I assume you use the TopIcon Plus extension? In that case I'd like to point out that a fix for the 'Icons not clickable in a wayland session' bug landed for GS 3.32 (and is likely to get backported). So you should be able to either use TopIcon Plus or the AppIndicator extension.

[ilippert]

interestingly, on wayland I get the icon, but clicking on it does not achieve anything.

I assume you use the TopIcon Plus extension? In that case I'd like to point out that a fix for the 'Icons not clickable in a wayland session' bug landed for GS 3.32 (and is likely to get backported). So you should be able to either use TopIcon Plus or the AppIndicator extension.

Thanks a lot, workaround with AppIndicator works perfectly