xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#638 closed enhancement (fixed)

system tray menu needs a command-launcher

Reported by: Richard Neill Owned by: Antoine Martin
Priority: major Milestone: 0.15
Component: server Version: trunk
Keywords: system tray, launcher, icon, xterm, run command Cc:

Description

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.

Attachments (2)

OSX-start-command.png (57.8 KB) - added by Antoine Martin 3 years ago.
where the start-command menu entry is shown on osx
ticket638-no_run-command.png (65.6 KB) - added by alas 3 years ago.
unhappy action menu

Download all attachments as: .zip

Change History (14)

comment:1 Changed 3 years ago by Antoine Martin

Component: androidserver
Milestone: 0.15
Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

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)

comment:2 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to Richard Neill
Status: assignednew

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

Note: because this allows you to run arbitrary commands on the server, this feature is disabled by default. You must set start-new-commands=yes in your config file, or use the command line argument --start-new-commands=yes when starting the server.

Please test and give feedback.

Last edited 3 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 3 years ago by Antoine Martin

Owner: changed from Richard Neill to alas

Not heard back, afarr? (mostly FYI)

comment:4 Changed 3 years ago by 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

comment:5 Changed 3 years ago by Antoine Martin

Summary: RFE: system tray menu needs a command-launchersystem tray menu needs a command-launcher
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.

comment:6 Changed 3 years ago by 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).

Changed 3 years ago by Antoine Martin

Attachment: OSX-start-command.png added

where the start-command menu entry is shown on osx

comment:7 Changed 3 years ago by 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:
where the start-command menu entry is shown on osx

comment:8 Changed 3 years ago by 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)

Changed 3 years ago by alas

unhappy action menu

comment:9 Changed 3 years ago by 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:


unhappy action menu

comment:10 Changed 3 years ago by Antoine Martin

Please provide the full command line used at both ends.

comment:11 Changed 3 years ago by alas

Owner: changed from alas to Antoine Martin

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).

comment:12 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.