Sync status icons not shown in Linux distributions

[jancborchardt]

(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]

* **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]

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]

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]

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]

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

[jancborchardt]

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]

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

[er-vin]

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]

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

[jancborchardt]

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]

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:

desktop/admin/linux/build-appimage.sh

Lines 60 to 68 in 7f7dd6b

	# Don't bundle nextcloudcmd as we don't run it anyway
	rm -rf ./usr/bin/nextcloudcmd
	# Don't bundle the explorer extentions as we can't do anything with them in the AppImage
	rm -rf ./usr/share/caja-python/
	rm -rf ./usr/share/nautilus-python/
	rm -rf ./usr/share/nemo-python/

[nicolasfella]

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]

@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]

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.

[er-vin]

@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]

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]

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]

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

[er-vin]

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]

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]

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]

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

[er-vin]

@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]

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]

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

[skewty]

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]

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

[Thatoo]

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 AppImage/AppImageKit#1179 (comment)

[marbx]

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]

@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]

@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]

@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]

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

[ivaradi]

@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]

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]

Maybe this one works better:

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

[marbx]

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:[email protected]>

 
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]

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

[marbx]

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 <[email protected]>
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]

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

[ivaradi]

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

[marbx]

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]

@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:

1. Install the gnome-shell-extension-appindicator package.
2. Log out of the GNOME session and log back in.
3. Using the Extensions tool, enable the "Ubuntu AppIndicators" extension.
4. (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]

@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.

[marbx]

Regarding an "official" solution to a system tray under Debian+GNOME, I found:

• A discussion about integrating the Appindicator extension into gnome
  • Which includes a link to the (tiny) "top-icons" extension on an unmerged Gnome branch which only has a "policy issue". Could "top-icons" be a solution?

Regarding "official" file manager icons:

• Gnome 3.26 included a library for cloud providers
  • Why doesn't NextCloud use it?

Until icons are missing, could the NextCloud desktop app use QSystemTrayIcon::isSystemTrayAvailable() to alert the user that the top icon (and file manager icons) are missing and how to work around?

As users must initially open the app to connect to their cloud, they would be notified of the workarounds. Otherwise, a lot users will be left frustrated, as I was myself, and many will simply assume the app does not work.

[RokeJulianLockhart]

git automatically adds sycnhronization-iconography to dolphin when installed via Fedora.