xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 2 months ago

#2286 closed defect (fixed)

@[email protected] does not function as documented

Reported by: deenoco Owned by: deenoco
Priority: minor Milestone: 3.0
Component: core Version: 2.5.x
Keywords: Cc:

Description (last modified by Antoine Martin)

from xpra manpage:

--title=VALUE
      Sets  the  text  shown as window title.  The string supplied can make use of remote
      metadata placeholders which will be populated at runtime with the values  from  the
      remote server.  The default value used is "@[email protected] on @[email protected]".

      The following placeholders are defined:

      @[email protected]
             Will be replaced by the remote window's title.

      @[email protected]
             Will be replaced by the remote server's hostname.

I interpret @[email protected] to mean the system running the xpra controlled X11-server but it appears to be the system where the x11-application is running instead.

The setup.

Let 'X' be the "local system" running the interactive X11-server with keyboard,mouse,monitors,...

  • 'X' is ubuntu 18.04lts
    $ uname -a
    Linux X 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
    
  • 'X' has xpra version
    $ xpra --version
    xpra v2.5.1-r22431
    
  • 'X' has .xpra/xpra.conf containing
    #
    # general options
    #
    readonly=no
    clipboard=yes
    clipboard-direction=both
    file-transfer=no
    open-files=off
    forward-xdg-open=off
    pulseaudio=yes
    
    #
    # Options for start, start-desktop, upgrade and attach
    #
    notifications=no
    bell=no
    remote-logging=no
    
    #
    # Options for attach
    #
    opengl=no
    title=xpra/@[email protected]:@[email protected]
    
    #
    # Options for attach, stop, info, screenshot, version
    #
    ssh=ssh
    

Let 'A' be a "remote system" running an xpra server on display :7 with a single xterm running on it with name/title shel[email protected]

  • 'A' is also ubuntu 18.04lts
    $ uname -a
    Linux A 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
    
  • 'A' has xpra version
            $ xpra --version
            xpra v2.5.1-r22431
    
  • Let 'B' be a remote system with no running xpra server.

'B' is reachabe from A via ssh
'B' is another ubuntu 18.04lts

        $ uname -a
        Linux  4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Note: 'X', 'A', and 'B' are distinct systems.


The issue.

'X' uses xpra attach ssh://A/:7

a single xterm appears locally with name/title as expected

xpra/A:[email protected]

in that xterm, the command

ssh B xterm -name [email protected]

a second xterm appears locally with the name/title

xpra/B:[email protected]

but the expected name/title is

xpra/A:[email protected]

to verify the new window is indeed associated with xpra server on 'A'
'X' uses:

xpra detach ssh://A/:7

both xterms with names/titles xpra/A:[email protected] and xpra/B:[email protected] disappear
'X' uses:

xpra attach ssh://A/:7

both xterms with names/titles xpra/A:[email protected] and xpra/B:[email protected] re-appear

I specifically chose using

title=xpra/@[email protected]:@[email protected]

to identify which windows are associated with different xpra controlled x11-servers. But it appears @[email protected] is actually showing the system the x11 application is running instead. I tried the experiment with two other x11-applications, xlock & oclock, getting the exact same results as when using the xterm. I use an icon manager that shows all windows, either iconified or not, that I have configured to sort on x11 window's name/title. The the leading "xpra/@[email protected]:" would group all windows associated an xpra server.


The requested changes.

If @[email protected] is indeed _always_ showing the system the x11-application is running upon, then

  • 1 for backwards compatibility, I would leave the @[email protected] functionality the same but update the documentation reflect this
  • 2: add a new string such as @[email protected] that expands to the system the xpra server is running upon

Since I did not do an all inclusive test, only using three x11-apps (xterm, oclock, and xclock): if @[email protected] for x11-apps run on remote systems with respect to the one running the xpra server sometimes shows x11-app system and other times shows the xpra system, then make @[email protected] consistently show one or the other _AND_ if @[email protected] will always show the x11-app system, then add @[email protected] from the above request.

An additional minor enhancement request. Invent a syntax that all allows a user to use the '@' character in the xpra title. For instance "\@". Thus,

title=xpra\@@[email protected]/@[email protected]

would show [email protected]/[email protected] as the name/title in above example.

And another additional enhancement request. Create another "@-string" to for the xpra server display, such as @[email protected] to get the X11 DISPLAY for that xpra server. Thus,

title=xpra\@@[email protected]@[email protected]/@[email protected]

would show [email protected]:7/[email protected] as the name/title in above example.

Attachments (1)

xpra-bug (5.2 KB) - added by deenoco 3 months ago.
bug-description-as-originally-formatted

Download all attachments as: .zip

Change History (4)

comment:1 Changed 3 months ago by deenoco

Sorry about the above formatting. The bug reporting gui seems to have "reworked" all the whitespace...

Changed 3 months ago by deenoco

Attachment: xpra-bug added

bug-description-as-originally-formatted

comment:2 Changed 3 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to deenoco

Sorry about the above formatting. The bug reporting gui seems to have "reworked" all the whitespace...

The wiki/WikiFormatting link is just above. (re-formatted by hand..)

The client-machine attribute comes from the window's WM_CLIENT_MACHINE property, if missing then the xpra server's hostname is used.
The man page now reflects this: r22561 + r22563.

As of r22562 you can now use "@@" to get one "@" displayed.

r22564 adds @[email protected] and @[email protected].
Manual page updates in r22565.
Better backwards compatibility in r22571.

@deenoco: please close if that works for you.

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

comment:3 Changed 2 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

Works for me.

Note: See TracTickets for help on using tickets.