Add integration to Nautilus file manager

[mazznoer]

Is your feature request related to a problem? Please describe.
cd to deep directory structure is hard.

Describe the solution you'd like
Add right click context menu to open wezterm using current directory from Nautilus.

Describe alternatives you've considered
[..]

Additional context
Example from Tilix.

[wez]

If you can find out how Tilix registers itself there, then that will help someone implement the same technique here!

[mazznoer]

• https://github.com/gnunn1/tilix/blob/master/data/nautilus/open-tilix.py
• Missed "Open Tilix Here" option in the Nautilus file manager. gnunn1/tilix#1529
• https://gitlab.gnome.org/GNOME/nautilus-python

[kar1]

https://help.ubuntu.com/community/NautilusScriptsHowto

Looks like one could make a shell script using these shell variables:

$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS
$NAUTILUS_SCRIPT_CURRENT_URI

And place it in ~/.local/share/nautilus/scripts/. I haven't tested it. But I'm not sure it's a good idea to install scripts there from an application installer. I would drown in open here options :-) I think it's meant for user made configurations. At least make it optional or provide a script the user can copy. I personally think it should go in the configuration guide. And yes I'm long overdue with the guide, which by the way have a small nautilus sections now :-D

[EpocSquadron]

I think packages are meant to use the equivalent path in /usr/share/nautilus/scripts.

[swsnr]

There's also a rust binding to Nautilus, see https://github.com/talklittle/nautilus-extension-rs/

I've started working on a plugin with that library, but I'm unsure whether it could find a place here. As far as I can see wezterm is MIT, however that binding is GPL-3, making any extension based on that effectively GPL-3 as well. Nautilus Python has a similar issue; it's GPL-2.

The underlying libnautilus-extension is LGPL-2, but I'd not like to resort to C just to avoid some license.

If GPL bars a nautilus extension from being included here, I'm happy to maintain it independently 🙂

[wez]

re: license question, it's OK to include the plugin crate here in a sub-directory. We can make it clear that just that directory is subject to GPL-3. In my mind the plugin would be essentially shelling out to launch wezterm or perhaps shelling out to wezterm cli in some cases to query stuff, so there shouldn't be a lot of wezterm specific "intellectual property" directly linked into the plugin, which will help to prevent infecting the rest of the code with the GPL.

re: maintaining it: I would love to not be the primarily responsible person for this component because I just don't use Nautilus enough to run it through its paces.

There's some administrative stuff to wrangle:

• CI should build it for X/Wayland systems (including FreeBSD in the end!), which may require some adjustments to the deps installed by CI the get-deps script
• The packaging stuff in ci/deploy.sh should put the plugin into a separate package so that GTK/Nautilus isn't required to run the main GUI package

Having the code live in this repo should make it easier for the plugin to appear in downstream distributions as more of them package up wezterm, which feels like it would be good for users.

[swsnr]

I didn't like those Rust bindings so I prototyped a small Python extension instead, see https://codeberg.org/flausch/dotfiles/src/commit/b892008767d8ebe58f9378c5ee1c757549de5f62/gnome/nautilus-extensions/wezterm-nautilus.py.

Currently it's rather dumb and just spawns a new wezterm instance and window every time the menu item's clicked, and entirely ignores multiplexing. If that's good enough I'm happy to contribute it, but I'm not sure I'd like to deal with the packaging stuff 😬 I looked at ci/deploy.sh and it's building RPMs and Debian packages; I don't know these formats, and my distribution has a different one 🙈 so those packages would be of no use to me 😇

It's also probably up for debate whether and how this extension should deal with multiplexing. I guess someone who's setup some multiplexing domains expects to have windows spawned in their preferred Unix multiplexing domain, but since there's no standard domain in WezTerm and people probably have different ideas about whether there should be new windows, or new tabs in existing windows, and which window to choose if there are multiple, etc. it's perhaps quite hard to get this right in a generic way 🤔

[wez]

Looks good!

Re: multiplexing, I'd suggest not worrying about it in this context. In the nightly builds, launching new programs via wezterm start will try to re-use the current GUI instance and I think that's good enough.

Packaging wise, here's what I suggest; looking at this bit that installs the equivalent thing for tilix:

https://github.com/gnunn1/tilix/blob/cb8ef536cb88f3d3d525654a88481cdc3d310f30/install.sh#L103-L105

I think the steps are:

• Import wezterm-nautilus.py as assets/wezterm-nautilus.py in this repo
• Add install -Dm644 assets/wezterm-nautilus.py %{buildroot}/usr/share/nautilus-python/extensions/wezterm-nautilus.py to the linux rpm build around here: https://github.com/wez/wezterm/blob/main/ci/deploy.sh#L158
• Add install -Dm644 assets/wezterm-nautilus.py -t pkg/debian/usr/share/nautilus-python/extensions/wezterm-nautilus.py to the deb build around here: https://github.com/wez/wezterm/blob/main/ci/deploy.sh#L206
• Do something equivalent to those for the appimage around here: https://github.com/wez/wezterm/blob/main/ci/appimage.sh#L12
• and then also for the PKGBUILD template around here: https://github.com/wez/wezterm/blob/main/ci/PKGBUILD.template#L57-L58 (that unpacks the appimage)

[swsnr]

I'll try to make a merge request. I've two more questions though:

1. Python extensions for nautilus require an extra package to bridge Python and nautilus which is not part of nautilus itself. How should I deal with this dependency? I can add a corresponding optdepends to the PKGBUILD, but I don't know how these things work with debs and rpms, and I do not know how the nautilus-python package is called in other distributions.
2. Does it make sense to add this file to the App image? Nautilus won't look into app image file systems, after all. Or is this just required to get the file over to the PKGBUILD?

[wez]

I'll try to make a merge request. I've two more questions though:

1. Python extensions for nautilus require an extra package to bridge Python and nautilus which is not part of nautilus itself. How should I deal with this dependency? I can add a corresponding optdepends to the PKGBUILD, but I don't know how these things work with debs and rpms, and I do not know how the nautilus-python package is called in other distributions.

Heh, I also have incomplete knowledge here :-)

If optdepends works for PKGBUILD then I think that's fine to do.

My understanding is that debian has a way to list optional dependencies, but I'm not sure about it. https://linuxhint.com/debian_package_dependencies/ seems to imply that it might be Recommends: rather than Depends.

I don't think you can have optional deps in rpms, but I also think that it is fine to deploy the script without listing a dep.

2. Does it make sense to add this file to the App image? Nautilus won't look into app image file systems, after all. Or is this just required to get the file over to the PKGBUILD?

Correct: It needs to be in the appimage for the PKGBUILD machinery to work and install it

[swsnr]

I've opened #1712

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.