Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Implementing Open in Remote Terminal context menu in nemo #2824

Closed
hsbasu opened this issue Aug 30, 2021 · 9 comments
Closed

Comments

@hsbasu
Copy link

hsbasu commented Aug 30, 2021

I was unsure whether to raise the issue here or not. So if the issue seems off-topic please close it.

Rather than an issue, This is a feature request.

I have used both caja and nautilus. In both the file-managers, within an sftp-connected remote directory, there is a context menu option Open in Remote Terminal. In a local directory, This option is hidden. However in nemo, even though the Open in terminal is present, the remote option is missing.

So I decided to take the matter into my own hands and started implementing the feature in nemo. I found that the Open in Terminal feature is implemented as an inbuilt action which is defined in src/nemo-actions.h.

In GUI, it is called from action_open_terminal_callback function in src/nemo-window-menus.c. But I am having trouble understanding the call of other functions like:

In file src/nemo-window-menus.c:
in function: action_open_terminal_callback

  1. nemo_view_get_uri at line 1282
  2. g_file_new_for_uri at line 1283
  3. g_file_get_path at line 1284 in function: open_in_terminal_other`
  4. g_settings_get_string at line 1265
  5. g_spawn_async at line 1267

P.S. I am using VS Code. But even it cannot trace those functions using key F12

@mtwebster
Copy link
Member

mtwebster commented Aug 30, 2021

the g_ functions are part of glib - what's essentially happening is:

  • get the uri of the current location (for local folders, it'd be something like file:///home/foo, for a remote fs it could be sftp://[email protected]/foo
  • Create a GFile for this uri - a GFile is not specific to nemo, and has all sorts of useful methods to operate on files.
  • Get the actual local path for this file
  • Get the user-defined default terminal program (GSettings is another generic object that connects to a service that stores program settings - this is similar to the windows Registry, but not nearly so complicated).
  • Open the terminal at that location.

If I connect to another machine via sftp (ssh in the Connect to server dialog), opening a terminal should work as is - most of the time remote locations are 'mounted' to a local path. I suppose that's why we've never had any previous request for what you're asking.

Both caja and nautilus provide this functionality using an add-on (extension). We'd probably want to do something similar here.

You could actually take a look at caja-open-terminal (or even port it to nemo, the api is pretty much the same), or have a look at Nemo Actions - while it's not powerful enough alone to do what's required here (the uri would need to be broken apart to separate the server address from the path, etc...), it could be paired with a script (in any language) that could set up the terminal and ssh.

Maybe this is more info than you wanted :) But feel free to ask any more questions.

edit: Forgot to link to the NemoAction sample/doc: https://github.com/linuxmint/nemo/blob/master/files/usr/share/nemo/actions/sample.nemo_action

@hsbasu
Copy link
Author

hsbasu commented Aug 30, 2021

Many thanks for the help. I already looked at the caja sources and using that as reference. May be I'll copy paste some of the codes while I try to implement this in nemo.

Right now I copied and modified the python code below and implemented the feature as nemo action using sample.nemo_action as base.

#!/usr/bin/python3
#remote_terminal.py
# -*- coding: utf-8 -*-

import os
import sys
import subprocess

terminal="gnome-terminal"

_path = sys.argv[1]
# print(_path)
_user = os.environ['USER']
# print(_user)

if '/sftp:' in _path:
    # print("remote")
    sftp = _path.split('/sftp:', 1)[1]
    settings = {}
    settings['user'] = _user
    options, sep, settings['path'] = sftp.partition('/')
    for opt in options.split(','):
        name, sep, value = opt.partition('=')
        settings[name] = value
    
    cmd = [terminal, '-e',
        'ssh %(user)s@%(host)s -t "cd /%(path)s; $SHELL"' % settings]
    subprocess.call(cmd)
    # print(cmd)
else:
    sys.exit(1)
#remote_terminal.nemo_action
[Nemo Action]
Name=Open in Remote Terminal
Comment=Open current directory in remote terminal
Exec=<remote_terminal.py %F>
Icon-Name=terminal
Selection=none
Extensions=dir;
conditions=exec <remote_terminal.py %F>;
Dependencies=ssh;

But there are issues with this. This action is always visible both in local and remote directory, while the action should only be visible in remote directories.

So I thought if both caja and nautilus is already providing it, then why should nemo be behind them and started implementing it in nemo.

Besides it is a very handy feature for new to intermediate users like me. Typing ssh and the whole hostname and then the full path(sometimes I need to dig into more than 10 levels of sub-directories) is very tedious, especially when you have to do it more then hundred times a day. So I use it to open remote terminals on centos remote workstations at the lab every time.

@mtwebster
Copy link
Member

Yes Nemo actions don't have the ability to look at uri schemes (file, sftp..) which I only now realize might be something useful to add. You also can't currently fetch the real uri of the current folder (right-clicking the background of the view), only the path.

Does the normal Open in Terminal not work for accessing your servers? As far as I know it should be as secure as a dedicated shell session.

I think I'd be ok adding this directly into nemo's source. Though the extension route does have an advantage that they can be written in python as well as C (have a look here for some python examples if you're interested.

@hsbasu
Copy link
Author

hsbasu commented Aug 30, 2021

Does the normal Open in Terminal not work for accessing your servers? As far as I know it should be as secure as a dedicated shell session.

Yes it does. But then I cannot use the packages that is available only on the remote system. For example, suppose I have icc (Intel C Compiler) on the remote system and not on the guest system. Currently I cannot invoke icc from the guest until I use ssh.

I think I'd be ok adding this directly into nemo's source. Though the extension route does have an advantage that they can be written in python as well as C (have a look here for some python examples if you're interested.

I also looked up this method. The nemo-terminal extension can be modified to provide the same feature. But I don't know whether that terminal can be detached from the nemo window. But one thing for sure if it provides detachable terminals then it'll be best to implement the feature there. It'll save us from modifying nemo's source as well as give us more freedom to maintain the feature.

I think it'll be better if other users also provide their opinions. That's why I opened this thread to know Mint developers' as well as Mint users' opinion.

@mtwebster
Copy link
Member

Ah yes, sorry. I didn't consider that.

@hsbasu
Copy link
Author

hsbasu commented Aug 30, 2021

BTW can you tell me how to compile and test nemo?

Should running dpkg-buildpackage --no-sign be sufficient to create a .deb package and install it, if I make any modifications?

@mtwebster
Copy link
Member

On mint, yes - you don't even need the --no-sign (it says it's an error but the packages are created anyhow).

You probably need to enable source repos and apt build-dep nemo first.

Once you've built once like that, you can rebuild/reinstall using sudo ninja -C obj-x86_64-linux-gnu install - just note, since you use sudo to install there, you'll have to sudo git clean --fdx if you want to do a real rebuild later (using dpkg-buildpackage).

Installing ccache will also help speed builds up - it gets noticed automatically by meson/ninja.

@hsbasu
Copy link
Author

hsbasu commented Aug 31, 2021

[Update] I tried to test nemo-terminal extension. But it's not so feature rich. For example,

  1. I cannot change the terminal font size.
  2. I cannot change the color scheme. I prefer a light colored terminal during day and a dark background during night. Also the other markup colors cannot be changed.
  3. I tried to understand which terminal is being used, as I have both mate terminal and gnome terminal. For that I tried to print and dig up the variable self.term=Vte.Terminal() but without any success.

@hsbasu
Copy link
Author

hsbasu commented Sep 5, 2021

@mtwebster With commit 8580163 It works fine now. I modified the remote_terminal.nemo_action to

[Nemo Action]
Name=Open in Remote Terminal
Comment=Open current directory in remote terminal
Exec=<remote_terminal.py %F>
Icon-Name=terminal
Selection=none
Extensions=dir;
conditions=exec <remote_terminal.py %U>;
Dependencies=ssh;
UriScheme=sftp

I suggest this action should be bundled along with other in-built actions like change-background.nemo_action

Should I close this issue?

@hsbasu hsbasu changed the title Implementing Open in Remote Terminal context menu in nemo [Feature Request] Implementing Open in Remote Terminal context menu in nemo Dec 14, 2021
hsbasu added a commit to mamolinux/nemo that referenced this issue Dec 16, 2021
"Open in remote terminal" option was missing in nemo context menu.
Added the option by creating a new in-built action in
/usr/share/nemo/actions which runs a python script to invoke ssh in
terminal. More detailed benefits can be found in linuxmint#2824
hsbasu added a commit to mamolinux/nemo that referenced this issue Dec 16, 2021
"Open in remote terminal" option was missing in nemo context menu.
Added the option by creating a new in-built action in
/usr/share/nemo/actions which runs a python script to invoke ssh in
terminal. More detailed benefits can be found in linuxmint#2824
@hsbasu hsbasu closed this as completed Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants