search

wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.9k stars 801 forks source link

Add integration to Nautilus file manager #1092

Closed mazznoer closed 2 years ago

mazznoer commented 3 years ago

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. nautilus-context-menu

wez commented 3 years ago

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

mazznoer commented 3 years ago
kar1 commented 3 years ago

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 commented 3 years ago

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

swsnr commented 2 years ago

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

wez commented 2 years ago

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:

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 commented 2 years ago

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 :grimacing: 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 :see_no_evil: so those packages would be of no use to me :innocent:

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

wez commented 2 years ago

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:

swsnr commented 2 years ago

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 commented 2 years ago

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.

  1. 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 commented 2 years ago

I've opened #1712

github-actions[bot] commented 1 year ago

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.