system tray menu needs a command-launcher

[Richard Neill]

I normally start the xpra server with "--start-child=xterm", then connect to it, and in the xterm, I run the commands I need, such as "thunderbird".

However, if I inadvertently close the xterminal on the display side, then there is no way to run further commands. Both sides are still running Xpra, but it's now necessary to shut them both down and re-start from scratch. (It's no good to SSH in, set $DISPLAY, and then launch another xterm, because then if the connection temporarily dies, all the programs get terminated).

I think it would be really useful if the system-tray menu on the client included at least one of the following:

• A menu item to start another xterm (fall back automatically to rxvt,konsole,or whatever is installed)

• A quick CLI to run an arbitrary command (like Alt-F2).

• A graphical launcher similar to the KDE/Gnome/... start menu.

Thanks for your consideration, and for a really useful tool.

[Antoine Martin]

Yes, I agree that this would be a useful feature.

Until I can get around to implementing it, I can offer some workarounds which will ensure the process does not get terminated when the ssh connection dies:

• use nohup
• disown the process after starting it in the background
• run in screen (or tmux)

[Antoine Martin]

Implemented in:

• r8303: preparatory work, moving stuff to server class (worth doing in its own right)
• r8305: support starting new commands via "xpra control" interface
• r8306: integration (see commit message)

How to use it:

• via "xpra control", ie:

  xpra control :10 start-child xterm
  

• via the new run-command dialog:
  • started from the tray menu
  • started via the shortcut Alt + Shift + F2

Please test and give feedback.

[Antoine Martin]

Not heard back, afarr? (mostly FYI)

[alas]

Testing with OSX client 0.15.0 r8522 against fedora 20 server 0.15.0 (supposedly r8522, but displaying as runknown)... I'm getting the following error output when trying the xpra control channel:

[jimador@zapopan ~]$ xpra control :23 start-child xterm
server returned error code 1
this feature is currently disabled
[jimador@zapopan ~]$ xpra control :23 start-child=xterm
server returned error code 6
invalid command

(Though, 'start-child' is listed as one of the valid control channel commands, when the "=xterm" command produces an error.)

Trying to use --start-new-commands=yes client side, obviously, fails.

There doesn't seem to be any sign of a run-command dialog on OSX (and the About Xpra menu option is displaying empty rectangles in lieu of text, I'll make a separate ticket for that, with screen shots... as the GUI launcher also seems to be doing this... hopefully not just because of the runknown server build).

Trying with windows 8.1 client 0.15.0 r8500, the xpra control channel produces the same results, but the run-command - when failing- produces the interesting bit of output server-side:

started child 'start-child xterm' with pid 8412
/bin/sh: start-child: command not found
child 'start-child xterm' with pid 8412 has terminated

[Antoine Martin]

this feature is currently disabled

Was a blooper - sorry about that, fixed in r8523.

Trying to use --start-new-commands=yes client side, obviously, fails.

Yes, that's as intended. The client does not get to choose if the feature is enabled or not on the server. It is listed in the "Server Controlled Features" in the xpra --help page.

Just to be clear, but I think you got that already: you must enable it in your server config by changing to: start-new-commands = yes in /etc/xpra/xpra.conf.
The syntax to use is the one from comment:2, no double dashes are ever used with the control channel command arguments, those are reserved for the "xpra" command itself.

There doesn't seem to be any sign of a run-command dialog on OSX

Oops, I keep forgetting that OSX does everything different "because shiny". So r8525 adds this new "Run Command" menu entry to the "Actions" global OSX menu.
(getting this simple thing to work on OSX took almost as long as the whole thing on client+server+every other platform. And infinitely more tedious. End of rant)

child 'start-child xterm' with pid 8412 has terminated

What did you type in the run command text input field?
All you need in there is "xterm" (or whatever). Works fine here and I get on the server:

started child 'xterm' with pid 9161

And the new window appears on the client.

[alas]

Testing again with fedora 20 server 0.15.0 r8527...

I did indeed input start-child xterm in the run command line. Inputting simply "xterm" works as expected.

The xpra control channel works as expected as well.

Testing with osx client 0.15.0 r8527, however, I'm still not finding the run-command option in the Actions global osx menu (though, with the Session Info gibberish output listed in #788, I am having a hard time confirming the osx client revision other than by the naming as part of the build).

[Antoine Martin]

where the start-command menu entry is shown on osx

[Antoine Martin]

I am having a hard time confirming the osx client revision other than by the naming as part of the build

xpra info | grep revision should show it as well.

I've uploaded a ​beta build so you can test it.

This is what it looks like:

[Antoine Martin]

You need to ensure --start-new-commands=yes is enabled on the server to see the start command option.. (it is off by default)

[alas]

unhappy action menu

[alas]

Testing again with fedora 20 server 0.15.0 r8601 (confirmed both in client output and xpra info) against osx client 0.15.0 r8640 (my build) ... I'm still not seeing any sign of a Run Command option in the Actions menu.

Instead, all I see is this:

[Antoine Martin]

Please provide the full command line used at both ends.

[alas]

Well that's embarrassing... sure enough, including the --start-new-commands=yes option made all the difference. See the Run Command option in osx, it works.

Looks good, assigning it back to you to close (after all that I don't trust myself to read correctly whether there are more bits to wrap up or not, though I think not).

[Antoine Martin]

Follow up: #1961.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/638