SSH session management

[Dan MacDonald]

Terminator is my fave terminal emulator - the only thing its missing for me is a nice way to manage SSH connections but I'm under the impression this is not a planned (integrated) feature for Terminator, is it?

What I want is a tree menu in which I can create folders to store and organise SSH connections. I envision two main uses:

* A quick way to open new Terminator tabs containing SSH sessions
* As an alternate method to create broadcast groups

I have found this:

https://github.com/mariolameiras/ssh-menu-terminator

However the problems are:

* It's not been updated since 2014
* It doesn't work under Terminator 1.9X (it's pre the GTK3 port)
* I have tried contacting the author about these issues but he hasn't replied

So, presuming this isn't a planned feature and the author doesn't reply to me I may fork his plugin and try updating it to work under terminator 1.9x. Has anyone got any tips for updating old plugins to work under the latest Terminator versions and do you think my idea about extending ssh-menu to be able to manage broadcast groups could work?

Thanks

[Stephen Boddy (stephen-j-boddy)]

You can use layouts to create presets and save the set of logins, editing the command to perform the ssh login. I know some people don't like this method, but I used it for a long time with great success.

I don't have something like you describe in my list. I'm sure it has been asked about in the past, but I can't find an existing wishlist item. If you want to go ahead and update the authors plugin, that's fine by me.

Tips:
 It is mostly a straight conversion from GTK2 to GTK3. The Terminator code itself has not really changed. GTK3 does throw up some annoying quirks, but till you start trying to run the code, you're unlikely to know what these are.

 There is a script out there that can do *some* of the donkey work. Search for pygi-convert.sh

 If you review the changes to the included plugins you'll get an idea of the sort of changes that are necessary. Just use:
bzr diff -r1520..1522 terminatorlib/plugins/
to look at the changes made for the included plugins. Omit the path to see all the changes for many, many more examples.

[Dan MacDonald (allcoms)]

Hi Stephen

Thanks for your great, quick answer! Thanks especially for pointing out pygi-convert.sh. By running ssh-menu.py though that script, it has fixed it enough so that ssh-menu appears as an option in the Terminator context menu and it opens a new window to display a (potential) list of SSH sessions. Its useless right now because you can't add any sessions/connections and so you can't start any SSH sessions either, but at least it is a step in the right direction.

Is this the best / most up-to-date guide to writing Terminator plugins:

http://www.tenshu.net/2010/04/writing-terminator-plugins.html

What would the average Terminator plugin dev/test cycle look like? Is there some special way to launch terminator when you're developing plugins so that I get more/better debug and/or it launches the plugin straight away?

I know some python and I wrote my own PyQt app recently so I should be able to handle something like this, with your help. If I make any progress I'll upload it to github and update this ticket.

Thanks

[Stephen Boddy (stephen-j-boddy)]

The doc you link to is old, but it is current as far as I'm aware. A manual is available now too, although the section covering plugins is a copy and paste from the tenshu one: http://terminator-gtk3.readthedocs.io/en/latest/plugins.html#creating-your-own-plugins

Nothing special for coding plugins. Just bash on it till you think it works, test, find bugs, repeat.

The standard "-d" flag can be used for debugging, although typically the plugins don't have a lot of debug statements. You can narrow it down by passing "--debug-classes SSHMenu" which would only give debug output from the plugin. However you'll need to add debug statements first as SSHMenu doesn't have any.

[Dan MacDonald (allcoms)]

Thanks for your tips Stephen, although I still haven't quite figured how to debug/test Term plugins. When I use the -d flag to start terminator, I get some debug output but I can't see anything relating to SSHMenu or plugins. If I use `--debug-classes SSHMenu`, with or without -d, I get no output at all.

I took note of what you said regarding SSHMenu not having any debug statements so I just stuck a random print statement within the __init__ method of the SSHMenu class but I don't see this being printed to the console from where I launched terminator (with the -d flag). The debug output seems to stop as soon as the term window is shown and I would presume my print statement would be expected to appear when the plugin is launched, not when terminator is loaded, right?

I've never done anything with (Py)GTK. I hope its as easy as PyQt as I found that quite straightforward, even for a total newb to GUI dev. I'll prob have to do some reading on PyGTK before I can make any progress with this but this could help:

http://dumbmatter.com/2012/02/some-notes-on-porting-from-pygtk-to-pygobject/

Thanks

[Dan MacDonald (allcoms)]

Hi Stephen

Hopefully you've just been too busy or just forgot to reply to me rather than me having opened a can of worms for you by asking about debugging plugins?

I'm quite keen to get started on this but I'm not going anywhere until I can see the errors, such as the existing ones in SSH-Menu that I'm no doubt just not seeing currently, or at least print stuff from within plugins so that I can get an idea where things are breaking.

Thanks

[Dan MacDonald (allcoms)]

I only see debug info relating to term plugins if I start terminator with:

terminator -d -d

BUT

It only shows debug info for plugins stored under /usr/lib/python2.7/site-packages/terminatorlib . I have tried copying ssh-menu.py (and ssh-menu.pyc) to that directory but term fails to see it when I move it there. Term only sees/loads ssh-menu if I have it stored under ~/.config/terminator/plugins/ but I never see any debug info relating to ssh-menu, regardless of if I start term with one or two -d switches.

I'm running Arch Linux x64.

[Dan MacDonald (allcoms)]

Sorry - ignore my last comment. ssh-menu does load if I copy it to /usr/lib/python2.7/site-packages/terminatorlib/plugins but that makes no difference to me on my quest to see plugin errors/debug stuff. Using one or two -d switches (and --debug-classes SSHMenu) isn't providing me the info I seek.

[Dan MacDonald (allcoms)]

I think I've spotted a big clue to the cause my probs. When I start term with -dd (or -d -d), I don't get an extra 'Open Debug tab' under the term context menu and nor do I see a 'Listening:' line in the term debug startup log.

Could it be that the Arch terminator package has been built with the wrong options and is missing whatever dep./configure option that is required to enable debugging? Unfortunately, archlinux.org is down ATM so I can't see the term PKGBUILD configure options used.

[Dan MacDonald (allcoms)]

The arch site is back. Here's what arch does to the term 1.91 source before installation:

# python2 fix
    for file in terminatorlib/{,plugins/}*.py; do
        sed -i 's_#!/usr/bin/python_#!/usr/bin/python2_' $file
        sed -i 's_#!/usr/bin/env python_#!/usr/bin/env python2_' $file
    done

    # fix run without gconf
    sed -i 's/except ImportError:/except ValueError:/' terminatorlib/config.py

I doubt any of those changes are responsible for my debug prob, are they?

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/terminator

[Stephen Boddy (stephen-j-boddy)]

Hi Dan. Sorry I haven't got back to you. Just busy.

#8 Be careful that you are not running another instance of Terminator, i.e. launch it from gnome-terminal. If you are trying to use Terminator to launch a debug Terminator you will also need to add the -u flag. Otherwise you are simply requesting another window from the already running, (presumably) non-debug Terminator. (This is the DBus functionality, and if it is causing you problems you can disable the DBus interface in your preferences.)

This might actually resolve *all* your issues with not seeing debug output, and get you well on your way to tackling the problems with the plugin.

[Dan MacDonald (allcoms)]

Hi Stephen

You're right - my problems were all caused by launching terminator (in debug mode) from within terminator. I'm now getting gorgeous pythonesque errors in some other terminal - I've never been happier to see some errors! :)

Thanks

[Dan MacDonald (allcoms)]

Hi Stephen

I've only done some minimal testing but I have now forked the SSH menu plugin github repo and patched it enough to get it working under Terminator 1.9x.

It has a few rough edges ATM but at least it works again. I'll see what I can do to make it more complete.

https://github.com/danboid/ssh-menu-terminator

[Dan MacDonald (allcoms)]

As for rough edges, the main issue with the SSH Menu plugin as it stands is that you currently need to close and re-open the SSH Menu window before newly added commands are displayed and deleted commands get removed.

The main feature that needs adding is the ability to create new command groups / tree groups to organise the commands with.

[Dan MacDonald (allcoms)]

Hi Stephen

I have updated my fork of the SSH menu plugin so that you can categorise the SSH connections / commands into groups.

The rough edges remain - I need to work on them but at least its closer to what I wanted now.

[Dan MacDonald (allcoms)]

Hi Stephen

I did a bit more work on the SSH Menu plugin today, fixing the command edit method to work with groups and tidying up / fixing another couple of minor things.

The problem now (and always has been, as this plugin never got finished), is that deleting (SSH) commands doesn't work when using the SSH menu plugin UI. The commands get deleted from the treeview OK, but they don't get removed from the terminator config file too because if you quit terminator, reload it and then load the SSH Menu plugin again, all of the supposedly deleted commands become visible again.

The workaround to this is to manually delete the unwanted commands from the terminator config file but I'd really like to have this working from the plugin UI.

I'd appreciate if you could have a look at the latest git source for this plugin and see if you can spot something I'm missing. I've been looking at the PyGTK docs and playing around with this all night. It looks like deleting commands should work properly as it is, but I'm very new to GTK.

Thanks

[Stephen Boddy (stephen-j-boddy)]

Hi Dan. First, a big props picking this up and getting it to date.

I haven't tested/run the code yet, but I think I spotted the problem using a quick differential with a similar bundled plugin. See http://bazaar.launchpad.net/~gnome-terminator/terminator/gtk3/view/head:/terminatorlib/plugins/custom_commands.py#L106

The standout part for me is that you are not (from my quick scan) deleting the old configuration, so your changes are always additive to the current config. Try adding that plugin_del_config call and see if it all starts to work. It is perhaps worth pointing out that Config is a borg object, only one of them can exist, and it is always the current config even when instantiating a new instance. This is why not actively deleting the old config will result in old config items sticking around after you save.

Hope that helps/fixes it :-)

[Dan MacDonald (allcoms)]

Hi Stephen

Thanks for your tip, you guessed correctly. I just had to add:

config.plugin_del_config(self.__class__.__name__)
config.save()

To the top of _save_config() and now all is well and so I think this plugin is ready to be used now. It might be worth changing the name as it would be useful for more than just SSH management.

The main thing I'd like to improve is fixing it so that there is no need to close and re-open the plugin window before changes are displayed in the Main menu treeview ie after adding or removing commands. Should this be doable or is it a limitation of the plugin system? I've not looked into it yet.

Thanks

[Stephen Boddy (stephen-j-boddy)]

The simplest thing to do is to call the save function whenever you make a change (add/edit/del). This would update Terminators internal state, and the menu should be immediately updated. It's not particularly elegant, but it should work. The disadvantage is that the Cancel button stops having an effect. Better would be to add an Apply button to the OK/Cancel area that calls the save function.

Of course the window is created as a modal window meaning that the launching instance of Terminator cannot be used until the configuration window is closed. Fixing that may be as simple as removing the modal flag at window creation time.

Also be aware that if you are running Terminator without DBus, then other instances of Terminator will not see the changes until they are restarted.

[Dan MacDonald (allcoms)]

No such luck.

By "calling the save function" I presume you mean the term. plugin save function, right? I have so far tried appending

config = Config()
config.save()

To the end of the callback and (main) menu methods as well as appending it to the "if res == Gtk.ResponseType.ACCEPT:" block within the configure method but none had the effect of updating the main window. The latter is where I expected / wanted to do the 'update main window' bit - I only really need the main window to update after the configuration window has been closed (OK'd) - would modal cause problems here?

I'm presuming there is no need to save any dummy data? The prob is that that bit of code was already saving the config via calling _save_config so I was surprised you said calling save might be the fix.

The plugin is still useful without this working but it would certainly be nice to have.

[Stephen Boddy (stephen-j-boddy)]

Sorry, I think I misunderstood what the issue was. I'll take another look when I get chance, as I'll need to get to my dev environment, and pull down your script to take a look.

[Stephen Boddy (stephen-j-boddy)]

OK, yeah, I totally misunderstood :-)

I see the problem now, but fixing it will take a bit of a refactor. You are creating a model when you construct the menu window. You create another *separate* model when you construct the config window. The user edits the second model with the config window, and when finished, writes this directly to the config file. The first model never gets updated. I see two possibilities:
1) Once the config has been written, trigger the menu window to re-read config. This is probably quicker and easier to do.
2) Another approach is to change all code to use a single shared model. This seems like it will be a bit more involved as my quick 60-second try failed elsewhere in the code. It would make the "Cancel" button in the edit window pointless however, which you might prefer to keep. Changes in edit would propagate immediately.

Small side note. Avoid tabs for indentation. Standard coding style for Terminator is 4 spaces per indentation level. Most editors can translate tabs to spaces for you, and handle indentation automatically.

Here's the changes I made to try and use a shared store, but it fails in the on_new method with an exception. And I have to stop now, so good luck ;-)

--- /home/steve/Downloads/ssh-menu-terminator-master/ssh_menu.py 2017-04-25 11:42:45.000000000 +0200
+++ ssh_menu.py 2017-04-26 08:26:15.459785141 +0200
@@ -26,6 +26,7 @@
     capabilities = ['terminal_menu']
     cmd_list = []
     conf_file = os.path.join(get_config_dir(),"ssh_menu")
+ store = Gtk.TreeStore(str,str,str)

     def __init__( self):
       config = Config()
@@ -130,15 +131,15 @@
     allgroups.append(self.cmd_list[elem]['group'])
       groups = list(set(allgroups))

- store = Gtk.TreeStore(str,str,str)
+ #store = Gtk.TreeStore(str,str,str)

       for group in groups:
- rabbit = store.append(None, [group,"blah","blah"])
- subgroup = [d for d in self.cmd_list if d['group'] == group]
- for command in subgroup:
- store.append(rabbit,[command['name'], command['command'], command['group']])
+ rabbit = self.store.append(None, [group,"blah","blah"])
+ subgroup = [d for d in self.cmd_list if d['group'] == group]
+ for command in subgroup:
+ self.store.append(rabbit,[command['name'], command['command'], command['group']])

- treeview = Gtk.TreeView(store)
+ treeview = Gtk.TreeView(self.store)
       selection = treeview.get_selection()
       selection.set_mode(Gtk.SelectionMode.SINGLE)

@@ -189,12 +190,12 @@
                         Gtk.STOCK_OK, Gtk.ResponseType.ACCEPT
                       )
                     )
- store = Gtk.ListStore(str, str, str)
+ #store = Gtk.ListStore(str, str, str)

- for command in self.cmd_list:
- store.append([command['name'], command['command'], command['group']])
+ #for command in self.cmd_list:
+ # store.append([command['name'], command['command'], command['group']])

- treeview = Gtk.TreeView(store)
+ treeview = Gtk.TreeView(self.store)
       #treeview.connect("cursor-changed", self.on_cursor_changed, ui)
       selection = treeview.get_selection()
       s...

[Stephen Boddy (stephen-j-boddy)]

Actually I just realized that the models are probably constructed differently, and would need to be aligned for this to work.

[Stephen Boddy (stephen-j-boddy)]

I just noticed something else. You removed the GPL v2 only notice from the source file. You probably shouldn't do that. Your modifications are automatically GPL v2 anyway.

[Dan MacDonald (allcoms)]

Hi Stephen

You're right, I shouldn't have removed the license notification so I've added that back in and I've got rid of the tabs now - sorry about that. The original author used two spaces for indent so I've stuck with that.

I was hoping there might be some magic one-liner to implement your first solution but from your response I presume not. At least now I can continue to hack at it now knowing I'm not trying to do something impossible for the current plugin system.

[Dan MacDonald (allcoms)]

Hi Stephen

I thought I'd have another look at the custom_commands plugin you linked to previously and I now realise that it seems to be the original source of SSHMenu and, being GTK3 compliant already, might've made for a better starting point. However, I think I prefer having the commands displayed in a separate window rather than within a submenu of the terminator context menu so I don't think my efforts have gone to waste.

[Stephen Boddy (stephen-j-boddy)]

Certainly not a waste. Yes, I had noticed the similarity in the windows and realized the code was derivative. First solution is unfortunately not a one liner. The shortest way would be to factor out the loading of config for the menu window out into a separate function, then after saving the new config, call that separate function to reload config.