desktop
desktop copied to clipboard
nextcloud
Sync status icons not shown in Linux distributions
(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-nautiluspackage? @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. :)
* **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.
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).
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.
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)
Yes, it's the same for dolphin (the package is dolphin-nextcloud). There are also packages for the nautilus variants, caja and nemo.
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 is for the PPA. For the AppImage, documentation and @DominiqueFuchs’s proposal would be workable.
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.
I know of no such possibility with apt and my brief research also turned up no positive results.
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.
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
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
@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.
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.
@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.
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.
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"
It also assumes that people use their DE's file manager, which is probably common, but not always the case
I didn't know
compulsory_for_desktopbefore 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.
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...
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 ;-)
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.
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?
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.
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).
@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 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.
@er-vin so, do you mean that the plugin packages should also have Enhances relations to nextcloud-desktop?
@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. :-)
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.