Since thunar has been rather unstable for me (and the regex batch renamer hasn’t been working recently, which was pretty much the main reason to use thunar), I wanted to use nautilus from a HM environment (i.e. without enabling gnome related settings system-wide.)
This appears to be much harder than expected due to the funky deps and limited config options to make nautilus aware of the locations of plugins.
So (the questions):
am I right this can only be done (consistently) by modifying/overriding the nautilus wrapper in nixpkgs (to support something like withPlugins or extraPackages)?
this would best require a HM module?
in general it seems “better” overall to have anything user-session related out of configuration.nix and rather in home.nix, at least for anyone using HM in the first place? (So this is why HM actually mirrors a lot of nixos functionality; in that sense anything user-session-related that’s missing could be considered missing coverage?)
I was surprised to not being able to find real solutions for the above given the perceived popularity of non-DEs (e.g. Hyprland) in combination with selective usage of gnome apps. (Let’s face it, life without gnome-keyring at least would be much more difficult, and some other gnome apps are pretty much the standard or at least quite useful (remmina, seahorse, virt-manager, meld, file-chooser, …).
So (further questions):
is it just me, or should we consider this as an infrastructural direction for UX improvement of NixOS+HM installs in general
is anyone already working on (parts of) this? (I found some hacks, but they solved only tiny parts of the problem)
Nautilus extensions are loaded from directory set using NAUTILUS_4_EXTENSION_DIR environment variable so you could create similar wrapper as Thunar has quite easily. I have this on my to-do list but probably will not get around to it any time soon.
Nautilus uses some service dependencies (e.g. Tracker), which cannot be expressed by plain Nix, so a module might be needed if you want to avoid installing all the dependencies manually.
With GNOME maintainer hat on, having explicit service dependencies mapped would be nice but personally, I am just focusing on GNOME as a whole. Due to global nature of services, implementing and then maintaining fully specified modules would require periodically running each app in a blank VM and checking there are no errors in the journal when trying to use app features. That would be a giant time sink unless upstream provides something like automated installed tests. But most apps do not have that.
I do not think either one is necessarily better than the other even for user-session stuff. Home-manager modules are needed to support non-NixOS hosts and allow different configuration per-user but some stuff (e.g. fully declarative dconf databases) can only be achieved in NixOS modules and they will probably always be better supported.
Nice step might be merging home-manager into Nixpkgs and then sharing the modules. But that would be huge effort of its own.
Thanks, ok that confirms my “fears” about the complexity, and I agree that the energy would be better spent on other things for now. So I guess I’ll abandon any deeper “HM-scope gnome integration” effort for my non-DE and just use the apps stand alone…
I tried something like that, but the difficulty seems to be that NAUTILUS_4_EXTENSION_DIR needs to be one directory, so I tried to use buildEnv to force the plugins under one path, but it seems there are some issues with relative dirs which I’m not at all sure how to debug or solve…
The last thing I tried was this, but I don’t see any plugins (other than the built-ins):
let
nautEnv = pkgs.buildEnv {
name = "nautilus-env";
paths = with pkgs; [
gnome3.nautilus
gnome3.nautilus-python
gnome3.gvfs
dconf
gsettings-desktop-schemas
gnome3.sushi
(python310.withPackages (p: with p; [ nautilus-open-any-terminal ]))
];
};
in {
home.packages = [ nautEnv ];
home.sessionVariables = {
GIO_EXTRA_MODULES = "${nautEnv}/lib/gio/modules";
NAUTILUS_4_EXTENSION_DIR = "${nautEnv}"; # https://github.com/NixOS/nixpkgs/blob/98da3dd0de6660d4abed7bb74e748694bd803413/pkgs/desktops/gnome/core/nautilus/extension_dir.patch#L18
};
}
Best case I might just be missing some suffix for the EXTENSION path?
gnome3 is not a thing any more, it is an alias for gnome and will be eventually removed.
NAUTILUS_4_EXTENSION_DIR needs to point to lib/nautilus/extensions-4/ subdirectory of the environment.
nautilus-python loads the scripts from nautilus-python/extensions/ directory relative to directories in XDG_DATA_DIRS (which needs to point to share/ subdirectory of the environment).
You should not need to pass nautilus-open-any-terminal to python310.withPackages.
sushi, gvfs and dconf require services to be installed. I guess including them in nautEnv and passing it to home.packages works but it will probably be cleaner to pass them to home.packages directly.
Thanks, that seems to make sense, but it appears it also means there is not really a unified way to handle extensions in HM. I refactored a bit (along your suggestions), but it doesn’t (yet) make a difference, since I guess it requires me to extend XDG_DATA_DIRS manually (for open-any-terminal to be discovered) and sushi doesn’t seem to expose things like extensions-4 because it’s not a “standard” plugin it seems.
It’s a bit too much of a rabbit hole I’m afraid, I guess I’ll get by without plugins or bite the bullet and install system-wide, even though I’m trying to keep user and system config pretty much separated.
It seems that your initial example almost works, I just added the /lib/nautilus/extensions-4 suffix to NAUTILUS_4_EXTENSION_DIR and the extension appears to load.
However, the menu option still offers to open Gnome Terminal even though I set /com.github.stunkymonkey.nautilus-open-any-terminal/terminal to foot in dconf settings. I suppose it still miss a tiny bit of gsetting wizardry
Cool! Nice that it works and makes some sense too
I moved to nemo since, and found it not only easier to integrate with plugins, but also have much better default side-bar handling for my taste (bookmarks and dir trees)
