Sync status icons not shown in Linux distributions

jancborchardt commented 4 years ago

(This is with Ubuntu 20.04 and GNOME 3.36.3, all current stable and freshly installed.)

Whether installing the Nextcloud desktop client 2.7.0 via AppImage or Ubuntu PPA, I don’t get file manager icons unless the nextcloud-client-nautilus package is installed, same as with the PPA (used the beta PPA).

Of course needing to install another package is not so nice, so it would be cool to do that automatically or improve the situation a bit. cc @ivaradi

For the Ubuntu PPA: Can we just install the nextcloud-client-nautilus package? @er-vin noted that there’s of course Kubuntu and other distributions which can use the PPA but might not use Nautilus – but a) we could just do this as a first step and b) I assume this can be checked somehow and a different fitting package be selected (or just skipped)?
For the AppImage: It apparently can’t do this according to @rullzer as it needs to integrate with the system and thus can’t install that package. @DominiqueFuchs suggested a great solution for a notice which could just be a dismissable box in the activity list:

As the AppImage already assures the platform by it‘s nature, one could relatively simple do a check for the package and provide a decent notice on first launch or similar. Just to prevent users who actually want that functionality assumings it‘s simply broken.
I didn’t test the Debian package or the Snap, does anyone know about that?

Since the AppImage is our default recommendation for installing on Linux, it would be nice to make this even better and just work – so if someone has insight or an idea, that would be cool. :)

er-vin commented 4 years ago

* **For the Ubuntu PPA:** Can we just install the `nextcloud-client-nautilus` package? @er-vin noted that there’s of course Kubuntu and other distributions which can use the PPA but might not use Nautilus – but a) we could just do this as a first step and b) I assume this can be checked somehow and a different fitting package be selected (or just skipped)?

Honestly please no nextcloud-client-nautilus hard dependency even as a first step. It'll pull stuff which will then linger on even once you get to a proper solution via suggestions or so (I'd even expect it to create difficulties to then migrate such setups to a proper solution). This wouldn't be acceptable on most setups.

er-vin commented 4 years ago

Oh I forgot something: I don't know what's the apt abilities around "suggests" are nowadays, but if they're too limited for apt to automatically pickup the right file manager integration package when one tries to install the client, I think the proper (fallback) solution would likely be a couple of meta packages to get client + whatever file manager plugin makes sense for the different ubuntu spins (so likely two metapackages or so).

ivaradi commented 4 years ago

The nextcloud-client-nautilus package is only a transitional package that depends on the nautilus-nextcloud package. nautilus-nextcloud itself depends on the nextcloud-desktop package, so if you install nautilus-nextcloud, you get the desktop client as well. Also, nautilus-nextcloud has an Enhances relation to nautilus, so I guess some package managers maybe able to recommend it if you have Nautilus installed.

That said, maybe I should just update the PPA description to indicate that if you have stock Ubuntu, you can just install nautilus-nextcloud. And similar updates could be done to other documentation as well.

er-vin commented 4 years ago

Yeah might turn out to be just a documentation issue... I guess the situation is similar for dolphin? (I mean those are the two filemanagers we support on Linux and so on Ubuntu spins)

ivaradi commented 4 years ago

Yes, it's the same for dolphin (the package is dolphin-nextcloud). There are also packages for the nautilus variants, caja and nemo.

jancborchardt commented 4 years ago

Is it somehow possible that it Just Works™ and gets installed with the nextcloud-desktop package? As you know, most people don’t read, and not only developers use Linux distributions (at least Ubuntu). ;) If we could update the documentation, we might as well just do it in the code and save work for thousands of people.

jancborchardt commented 4 years ago

That is for the PPA. For the AppImage, documentation and @DominiqueFuchs’s proposal would be workable.

er-vin commented 4 years ago

Is it somehow possible that it Just Works™ and gets installed with the nextcloud-desktop package? As you know, most people don’t read, and not only developers use Linux distributions (at least Ubuntu). ;) If we could update the documentation, we might as well just do it in the code and save work for thousands of people.

That's the part where @ivaradi wisdom is welcome. Is there a way for apt to figure out that you got (nautilus|dolphin|caja|nemo) installed and so auto-install only (nautilus|dolphin|caja|nemo)-nextcloud when the user install nextcloud-desktop the first time? If apt doesn't have this ability I don't think we can do better than document it without pulling in crazy platform specific code involving a support matrix as big as the number of file managers times the number of package managers.

ivaradi commented 4 years ago

I know of no such possibility with apt and my brief research also turned up no positive results.

jancborchardt commented 4 years ago

Is there a way for apt to figure out that you got (nautilus|dolphin|caja|nemo) installed

@er-vin @ivaradi I found 2 possible ways which seem to be cross-platform and not dependent on the package manager: xdg-mime query default inode/directory or which [file manager package].

On Ubuntu with GNOME and Nautilus they return:

~: xdg-mime query default inode/directory
org.gnome.Nautilus.desktop

~: which nautilus
/usr/bin/nautilus
~: which dolphin
~: which caja
~: which nemo
~: which thunar

On Fedora with GNOME and Nautilus it works as well, however with different output for the non-installed file managers on which:

~: xdg-mime query default inode/directory
org.gnome.Nautilus.desktop

~: which nautilus
/usr/bin/nautilus
~: which caja
/usr/bin/which: no caja in (/home/liveuser/.local/bin:/home/liveuser/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin)
~: which nemo
/usr/bin/which: no nemo in (/home/liveuser/.local/bin:/home/liveuser/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin)
~: which dolphin
/usr/bin/which: no dolphin in (/home/liveuser/.local/bin:/home/liveuser/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin)
~: which thunar
/usr/bin/which: no thunar in (/home/liveuser/.local/bin:/home/liveuser/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin)

If this works on other distros as well (please check), it would not make it a matrix, but a simple short if-else list, with the most popular file managers being covered. And I’d say that’s not too much in order to make sure it works out of the box for most.

misch7 commented 4 years ago

I don't know if it's relevant but in the AppImage build we're getting the following CMake warning:

  By not providing "FindKF5.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "KF5", but
  CMake did not find one.

  Could not find a package configuration file provided by "KF5" (requested
  version 5.16) with any of the following names:

    KF5Config.cmake
    kf5-config.cmake

  Add the installation prefix of "KF5" to CMAKE_PREFIX_PATH or set "KF5_DIR"
  to a directory containing one of the above files.  If "KF5" provides a
  separate development package or SDK, be sure it has been installed.

Dolphin plugin disabled: KDE Frameworks 5.16 not found

Maybe this framework would also be required to support Dolphin, but I'm not deep enough into this stuff, e.g. if this type of integration would be appropriate for the AppImage.

Also noteworthy, in our build scripts we have some forced exclusions so far: https://github.com/nextcloud/desktop/blob/7f7dd6bc766d01247afca44b29d8a9552559e4b5/admin/linux/build-appimage.sh#L60-L68

nicolasfella commented 4 years ago

Yes, that would be required for the Dolphin plugin. However it doesn't make much sense for the appimage build anyway. The Dolphin integration works by installing a .so file that then gets loaded by Dolphin. Therefore it cannot be part of the appimage and needs to be distributed individually. Adding the Dolphin stuff to the exclusion list would make sense

ivaradi commented 4 years ago

@jancborchardt the problem is not whether it can be detected in general which file manager is installed, but how this could be told to apt (and related tools) to install another package automatically if certain conditions hold. I know of no such way. One idea would be to install the file manager-specific package from, say, the post-install script, but it is not possible, since the package databases are locked when those scripts are running.

Another idea could be to just install these extensions all the time, but at the minimum they depend on other libraries, such as the corresponding file manager's plugin integration libraries, and you probably don't want to bloat your system by installing all of them. (Actually, the extension packages also depend on the file manager package, but such a dependency is probably not really necessary.) Now, one could just install the files and no dependencies, but, for example, the Nautilus family depend on the Python support libraries of the file manager, and they are not installed automatically by the file manager packages. So there would still be a requirement to manually install the support library.

nicolasfella commented 4 years ago

Something that could be done is detecting the default (all installed?) file managers, map that to an appstream id of the extension package with a curated list and propt the use to install it by opening the appstream:// URL. I guess something like that was the motivation behind https://github.com/nextcloud/desktop/pull/2220? This would open the system's respective app center (Discover, Gnome Software, etc) and allow installation with just a few clicks. Not entirely automated, but would be independent from apt and packaging mechanisms and would even help for the Appimage. This assumes that the extensions are packaged separately and not part of a big nextcloud package, but in that case we wouldn't have the problem in the first place.

er-vin commented 4 years ago

@jancborchardt the problem is not whether it can be detected in general which file manager is installed, but how this could be told to apt (and related tools) to install another package automatically if certain conditions hold. I know of no such way. One idea would be to install the file manager-specific package from, say, the post-install script, but it is not possible, since the package databases are locked when those scripts are running.

Yes, using xdg-mime is easy it's mostly pervasive these days, the real challenge is then figuring out the right package name for the distro and to trigger the installation (with all the fun regarding privilege escalation). To be fair: some of that "triggering the installation" pain is slightly alleviated if we assume PackageKit to be around... that won't solve the "figuring out the right package name" though.

In any case, putting code for that in the desktop application seems wrong to me, this is a distro and packaging prerogative and I think it should stay that way.

That being said... distros are slowly moving towards "app store"-like applications for user to install components and those are using more and more appstream data. That's something we don't provide today and maybe we could provide. I'm far from being an appstream expert though but it seems to allow to describe the fact that we got components specific to a desktop using the "compulsory_for_desktop" element. If that works, this wouldn't solve it for Ubuntu users using the command line but that'd solve it for everyone else using a GUI application using appstream.

er-vin commented 4 years ago

Something that could be done is detecting the default (all installed?) file managers, map that to an appstream id of the extension package with a curated list and propt the use to install it by opening the appstream:// URL. I guess something like that was the motivation behind #2220? This would open the system's respective app center (Discover, Gnome Software, etc) and allow installation with just a few clicks. Not entirely automated, but would be independent from apt and packaging mechanisms and would even help for the Appimage. This assumes that the extensions are packaged separately and not part of a big nextcloud package, but in that case we wouldn't have the problem in the first place.

Ah well, we posted around the same time. :-)

This indeed could be a path forward but I'm not even sure it'd be required if we provided appstream data in the first place (and we'd need to do it for your proposal to work). Hm... right that'd allow to catch those who installed just the client via the command line I guess.

It'd complete nicely what I had in mind I guess. This way if you install the client from an app center you get the right file manager extension right away, if not we propose its installation from a notification with a simple appstream URL... this could also solve the appimage case somewhat.

That starts to look like a plan.

nicolasfella commented 4 years ago

I didn't know compulsory_for_desktop before but looking at it I don't think it does help us with what we want. IIUC it models dependencies like "KWin is required for Plasma" and not "If you install Nextcloud on Plasma you need nextcloud-dolphin"

nicolasfella commented 4 years ago

It also assumes that people use their DE's file manager, which is probably common, but not always the case

er-vin commented 4 years ago

I didn't know compulsory_for_desktop before but looking at it I don't think it does help us with what we want. IIUC it models dependencies like "KWin is required for Plasma" and not "If you install Nextcloud on Plasma you need nextcloud-dolphin"

Ah right, I read it the other way around... We're kind of back to how the package manager works.

For the record and to highlight how it could (and imho should) behave at the package manager level: I'm using openSUSE and zypper understands the "supplements" relationship. For instance the nextcloud-desktop-dolphin package is declared to supplements "nextcloud-desktop and dolphin", so as soon as you install nextcloud-desktop while dolphin is already there it will also install nextcloud-desktop-dolphin automagically (this works the other way around too, you had already nextcloud-desktop and you install dolphin, it'll pull nextcloud-desktop-dolphin). They did the same thing for nautilus-extension-nextcloud and friends...

This is thus seamless... and for good reasons this is intrinsically a package manager (or app center) task.

er-vin commented 4 years ago

Alright, isn't what I'm describing the Enhances relationship for debian packages? https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

We seem to use it but declare it only for the filemanager not for nextcloud-desktop, could it be what's missing?

I'm definitely no expert in debian packaging though...

jospoortvliet commented 4 years ago

What I wonder is - why go through all this trouble? If it is just a few .so files in strategic locations (kuch) why not simply include them, with the normal desktop client, always. If the file is there but the file manager is not installed - nobody gets hurt. I mean, what did we do, waste 45 kb of user disk space (that's how big the dolphin plugin file is here)? If the file manager is installed, it uses the file, and things work.

We get what @jancborchardt (and of course, our users) want, and no extra work.

Is it dirty? Maybe, but Nextcloud at least has always chosen to do the dirty thing if it's a choice between something that helps the user and is dirty or something that makes the life of the user harder but is 'technically clean'. Think about Collabora Online ;-)

ivaradi commented 4 years ago

It is possible, but the question then becomes whether we then depend on the file managers' support libraries, such as python3-nautilus, python3-caja, etc, or not. If we depend on them, these packages also depend on a lot of other packages. In case of the Dolphin plugin, the plugin package currently depends on the dolphin package itself.

On the other hand, if we do not depend on these packages, just install these few files, the users may need to install the support library packages, so that the plugins work, i.e. we have the same problem.

er-vin commented 4 years ago

Yes, not that simple indeed, you'd be just kicking the problem one more level down in the dependency chain and it'll become even more obscure to the user IMO.

That Enhances relationship seemed promising though and would be a tiny fix to our debian packaging if that indeed works as I suspect. Any idea about that @ivaradi? Or I'm looking completely at the wrong place?

jospoortvliet commented 4 years ago

It is possible, but the question then becomes whether we then depend on the file managers' support libraries, such as python3-nautilus, python3-caja, etc, or not. If we depend on them, these packages also depend on a lot of other packages. In case of the Dolphin plugin, the plugin package currently depends on the dolphin package itself.

On the other hand, if we do not depend on these packages, just install these few files, the users may need to install the support library packages, so that the plugins work, i.e. we have the same problem.

Ah, ok, yeah, the dependencies complicate things. For Dolphin it isn't an issue, but if you need python3 for Nautilus and Caja, things get painful.

Though - do Nautilus users have python3-Nautilus typically (or even always?) installed? If not, then this is not a solution :sob:

This whole "let's spit everything up as small as possible" thing is really silly :( If distro's would be less extreme in that, something like AppImage would be far less desirable.

er-vin commented 4 years ago

Though - do Nautilus users have python3-Nautilus typically (or even always?) installed? If not, then this is not a solution sob

From the dependencies declared in the nautilus package I'd say the answer is: not if they didn't have to install a python based extension.

This whole "let's spit everything up as small as possible" thing is really silly :( If distro's would be less extreme in that, something like AppImage would be far less desirable.

YMMV depending on the distro of course... and some seems to have better dependency management than others (see my ramblings above).

ivaradi commented 4 years ago

@er-vin The Enhances relations are already there. Though, I have no idea how graphical package managers use them. I use command-line and I don't even use any of the graphical file managers, so I live in a blissful ignorance of this whole problem :)

@jospoortvliet on my machine python3-nautilus is not installed. and we would not need python3-nautilus only, but also python3-caja, python3-nemo, etc. end even dolphin. Why would I have to get Dolphin installed on a stock Ubuntu desktop?

er-vin commented 4 years ago

@er-vin The Enhances relations are already there. Though, I have no idea how graphical package managers use them. I use command-line and I don't even use any of the graphical file managers, so I live in a blissful ignorance of this whole problem :)

Yes @ivaradi, we got Enhances for the file managers but my point was that those packages don't have Enhances for nextcloud-desktop itself (while those packages enhance both, so probably both should be declared).

This should BTW have nothing to do with GUI package managers, apt itself deals with Enhances anyway.

ivaradi commented 4 years ago

@er-vin so, do you mean that the plugin packages should also have Enhances relations to nextcloud-desktop?

er-vin commented 4 years ago

@er-vin so, do you mean that the plugin packages should also have Enhances relations to nextcloud-desktop?

Well, as I mentioned I'm not debian packaging expert at all, but that would be my guess. It's kind of an inverted recommand so I'd understand it as "when you install X also install everything which enhances it". So right now I guess that if you got nextcloud-desktop installed and you install say nautilus, due to the Enhances relationship it'll pull in nautilus-nextcloud. But if you got nautilus already here and you install nextcloud-desktop, there's currently no reason to investigate nautilus-nextcloud because the relationship is not there.

Not sure if I make sense. Would need to be tested in any case. :-)

ivaradi commented 4 years ago

I have added a Suggests: relation from nextcloud-desktop to the various file manager plugin packages. Enhances is supposed to be a reverted Suggests relation, and since all concerned packages are under our control, I thought Suggests is more straightforward. But if it does not work, we can try Enhances.

The change is on the master branch, i.e. in the alpha repository.

er-vin commented 4 years ago

So the packages in the alpha directory have the Enhances relationship? It's just about someone trying it then I guess. :-)

skewty commented 4 years ago

Ah, ok, yeah, the dependencies complicate things. For Dolphin it isn't an issue, but if you need python3 for Nautilus and Caja, things get painful.

Python 2.7 is EOL and no longer gets updates. Because of this distributions must bundle Python 3 interpreters (so they can meet security goals / guarantees). A python3 dependency, now, is a very safe dependency in my opinion. What popular distro does not bundle it?

Thatoo commented 2 years ago

Any news on integration between the appimage and file managers (nautilus|dolphin|caja|nemo)?

Thatoo commented 2 years ago

Hoping that would be of any help :

Nextcloud would need to add code that would write the necessary files to the respective locations within $HOME (e.g., upon each launch of the Nextcloud client). When writing such code, they could check for the presence of the $APPIMAGE environment variable and use its value if available. When doing this, they might also want to add an option to uninstall such desktop integration (by deleting the respective files). I'd be happy to support Nextcloud devs if questions arise.

I don't know whether ownCloud has more functioniality regarding this, but it probably wouldn't hurt to check.

Originally posted by @probonopd in https://github.com/AppImage/AppImageKit/issues/1179#issuecomment-1060014583

marbx commented 2 years ago

Situation on GNOME 3 (Debian 11)

Issues:

No sync status icons in the file manager
No system tray icon

Steps to reproduce:

Installed Debian 11, all settings left as default
Installed Nextcloud via "Software"

Workaround for sync status icons in the file manager:


sudo apt install nautilus-nextcloud

ivaradi commented 2 years ago

@marbx

As discussed above, it is unfortunately not feasible to automatically install nautilus-nextcloud with the desktop client.

As to the system tray icon: since you mention an apt command, I assume you use the Ubuntu PPA. There is, however, a build for Debian (Testing, but it is hopefully close enough for Bullseye): https://download.opensuse.org/repositories/home:/ivaradi/Debian_Testing/. Could you try this one instead of the PPA?

marbx commented 2 years ago

@ivaradi, I installed non-free Debian11, for the non-free Wifi drivers, but I don't use any Ubuntu archive.

apt, I read somewhere, was developed by Ubuntu, but backported into Debian and Debian encourages its use on the command line.

I am glad to help you with testing. Which file exactly shall I install? I will set up a new Debian11 for the test.

ivaradi commented 2 years ago

@marbx, so it seems that you use the official Debian packages. I am not the maintainer of those packages, so I cannot help with them.

However, as I mentioned above, there is a build for Debian that I maintain. The repository for Debian 11 is at https://download.opensuse.org/repositories/home:/ivaradi/Debian_11/. So, please, configure this repository and try to install the desktop client from it.

(Actually, AFAIK, apt was developed for Debian, it is just that people seem to find the Ubuntu PPA and use that for all kinds of Debian/Ubuntu-based distributions, hence my (wrong) assumption.)

marbx commented 2 years ago

@ivaradi, I don't know how to configure your repository. Could you please explain?

ivaradi commented 2 years ago

@marbx you need to add a line like below to your /etc/apt/sources.list:

deb https://download.opensuse.org/repositories/home:/ivaradi/Debian_11 /

marbx commented 2 years ago

Adding a lines was not enough, apt requries a key.

Following stackoverflow

I did

wget -O- https://download.opensuse.org/repositories/home:/ivaradi/Debian_11/Release.gpg |\
    gpg --dearmor |\
    sudo tee /usr/share/keyrings/ivardi-nextcloud.gpg > /dev/null

Then I edited /etc/apt/sources.list

deb [signed-by=/usr/share/keyrings/ivardi-nextcloud.gpg] https://download.opensuse.org/repositories/home:/ivaradi/Debian_11 /

But sudo apt update still fails with

Hit:4 http://ftp.halifax.rwth-aachen.de/debian bullseye-updates InRelease
Err:2 https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 97E98EAFE52838E6
Reading package lists... Done
W: GPG error: https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 97E98EAFE52838E6
E: The repository 'https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Please advise

ivaradi commented 2 years ago

Maybe this one works better:

wget -nv https://download.opensuse.org/repositories/home:/ivaradi/Debian_11/Release.key -O - | sudo apt-key add -

marbx commented 2 years ago

after apt-key add, apt-key list shows

/etc/apt/trusted.gpg
--------------------
pub   rsa2048 2017-01-19 [SC] [expires: 2023-07-20]
      7EA2 F89D FE8C E90B C138  5D4D 97E9 8EAF E528 38E6
uid           [ unknown] home:ivaradi OBS Project <home:ivaradi@build.opensuse.org>


sudo apt update
Get:4 https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  InRelease [1,516 B]
Err:4 https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 97E98EAFE52838E6
Reading package lists... Done
W: GPG error: https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 97E98EAFE52838E6
E: The repository 'https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

ivaradi commented 2 years ago

What if you copy Release.key under /etc/apt/trusted.gpg.d, and rename it so that its suffix is .asc?

marbx commented 2 years ago

sudo cp Release.key /etc/apt/trusted.gpg.d/ivaradi.asc

Is insecure but it works:

sudo apt update
Get:4 https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  InRelease [1,516 B]
Fetched 1,516 B in 1s (2,590 B/s)                            
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

Now there are 3 nextcloud-desktop packages, one is

sudo apt show   nextcloud-desktop 
Package: nextcloud-desktop
Version: 3.5.3-20220729.170743.c48a8d89e-1.0~testing1
Maintainer: ownCloud for Debian maintainers <pkg-owncloud-maintainers@lists.alioth.debian.org>
APT-Sources: https://download.opensuse.org/repositories/home:/ivaradi/Debian_11  Packages

Installed with

sudo apt install  nextcloud-desktop=3.5.3-20220729.170743.c48a8d89e-1.0~testing1

Connected to my NextCloud, rebooted, NextCloud client is started automatically but there is no NextCloud status icon in the GNOME3 menu.

marbx commented 2 years ago

@ivaradi, the test of your package was about the status icon in the upper right menu bar?

ivaradi commented 2 years ago

@marbx, what test do you refer to? I have not tested the package on Debian 11.

marbx commented 2 years ago

I was under the impression you suggested to install your package because it enables the system tray icon.

Why did you suggest to install it?

ivaradi commented 2 years ago

@marbx I suggested to install it, because it is different from the one in Debian, and I hoped that it may work out of the box. I had no Debian 11 installation, thus have never tested if the Debian 11 package actually works.

However, I have just had time to experimenting with it in a Debian 11 VM, and found a solution, or at least a workaround:

Install the gnome-shell-extension-appindicator package.
Log out of the GNOME session and log back in.
Using the Extensions tool, enable the "Ubuntu AppIndicators" extension.
(Re)start the Nextcloud client (maybe another logging out of the session is needed before).

The hint was that the log (in ~/.config/Nextcloud/logs) contained entries like "System tray is not available, waiting...". This is printed when QSystemTrayIcon::isSystemTrayAvailable() returns false, i.e. when Qt does not find any system tray running. I am not sure what the "official" solution to a system tray under Debian+GNOME is, but the above seems to work. Actually, GNOME developers removed the concept of a system tray some time ago, so where there is one, it is always provided by extension.

marbx commented 2 years ago

@ivaradi, I confirm your procedure is working.

I also understand from this discussion that the Linux package on GNOME3 require users to be aware and capable of manually installing other packages and perform configuration.

nextcloud / desktop

Sync status icons not shown in Linux distributions #2217