xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 5 weeks ago

#1934 closed defect (fixed)

improved window filters: recursion, etc

Reported by: Antoine Martin Owned by: J. Max Mena
Priority: major Milestone: 2.4
Component: server Version: 2.3.x
Keywords: Cc:

Description

Following up #489.

Try to match properties of the parent window(s) for popup windows.
Make it easier to come up with more advanced filter matching scenarios.

Attachments (1)

window-filters.patch (10.2 KB) - added by Antoine Martin 3 months ago.
work in progress: control commands, inject x11 filters, etc

Download all attachments as: .zip

Change History (7)

Changed 3 months ago by Antoine Martin

Attachment: window-filters.patch added

work in progress: control commands, inject x11 filters, etc

comment:1 Changed 3 months ago by Antoine Martin

Status: newassigned

Done in r20080, this applies to x11 properties only because traversing the window tree is actually hard if we want to access the windows using their window models.. so we don't support that yet.

The rule matching is quite dumb: if any window filter matches the window then we only send that window to the sources that match the source's uuid (wildcard '*' can be used to match all sources).

It would be better to allow combination of rules to be used, the easiest way would be to provide a weight with each rule.
(otherwise we end up having to invent a grammar)

Examples:

  • start a server with an xterm:
    xpra start :100 --start=xterm
    
  • restrict the xterm to the client whose uuid is '1'
    xpra control :100 add-window-filter x11:window WM_CLASS = xtermXTerm '1'
    
  • connect a client and force its uuid to be '1':
    XPRA_USER_UUID=1 xpra attach --sharing=yes
    

(the xterm should show up)

  • connect a client and force its uuid to be '2':
    XPRA_USER_UUID=2 xpra attach --sharing=yes
    

(the xterm should not show up)

  • then to make it more interesting, we add some recursive window-title matching:
    xpra control :100 add-window-filter x11:window-parent _NET_WM_NAME = Foo '2'
    

Then start a test application whose window title will be 'Foo':

./tests/xpra/test_apps/test_window_title_fixed.py Foo

(this should only show up on client 2. and this is recursive, so right clicking in the input field will popup a window only on client 2)

  • repeat with more restrictions and more windows:
    xpra control :100 add-window-filter x11:window _NET_WM_NAME = Bar '1'
    
    ./tests/xpra/test_apps/test_window_title_fixed.py Bar
    

(only on client 1 - but not recursive this time, so the popup window will show on both clients!)

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

comment:2 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

Other examples:

  • never show xterms (unless a user cheats and claims the magic 'DISABLED' uuid):
    xpra control :100 add-window-filter x11:window WM_CLASS = "xtermXTerm" 'DISABLED'
    
  • filter using plain window model properties (non-x11 properties, not recursive and requires fix from r20082):
    xpra control :100 add-window-filter window pid = `pidof xterm` "1"
    
  • reset everything:
    xpra control :100 remove-window-filters 
    

Notes:

  • changing filters whilst running can make windows unresponsive on the clients that have their access cut off
  • the old instructions from #489 should be ignored, this ticket is the new reference - there are some known bugs in the implementation found in older versions, those won't be fixed

comment:3 Changed 7 weeks ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

For reference: I'm running a Fedora 28 server with trunk r20535, a Fedora 28 client also running trunk r20535, and a Win8.1 client running 2.4 r20529 x86_64.

After talking this over with Smo, I feel like I have a solid enough understanding of what this does to finally test this. I carved out some time yesterday and played around with it, and I got the Xterm demo to work - the first example, that is. (Only showing an Xterm to client UUID=1)

However, I can't seem to get the xpra control :100 add-window-filter x11:window-parent _NET_WM_NAME = Foo '2' one to work. I've tried running that command before launching the Python script and after the Python script (after shutting the whole server down between tests), and in both cases, the Foo window and the popup show up on both clients.

So, I'm well outside my knowledge-base here, so I'm not sure if I'm doing something wrong, or if there's a bug.

Here's what I ran:

  • Serverside:
xpra start :15 --start=xterm --bind-tcp=0.0.0.0:2200 --sharing=yes --start-new-commands=yes
xpra control :15 add-window-filter x11:window WM_CLASS = xtermXTerm '1'
xpra control :15 add-window-filter x11:window-parent _NEW_WM_NAME = Foo '2'
xpra control :15 start-child "python /home/max/Xpra/tests/xpra/test_apps/test_window_title_fixed.py Foo"
  • Client side:
    XPRA_USER_UUID=1 xpra attach tcp:192.168.1.81:2200 --sharing=yes
    

on the Fedora box, and

set XPRA_USER_UUID=2
Xpra_cmd.exe attach tcp:192.168.1.81:2200 --sharing=yes

On the Windows machine.

With both clients attached, I see the Python window on both clients, when I should only be seeing it on the Windows client since that one is UUID=2.

Antoine:

Is there anything overtly wrong with what I ran? Or did I run into some kind of bug. In which case, what logs should I be checking for?

Last edited 7 weeks ago by Antoine Martin (previous) (diff)

comment:4 Changed 7 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

Is there anything overtly wrong with what I ran?

Yes. You have a typo, it's _NET_WM_NAME.

r20543 adds "-d filters" debug to make these errors easier to debug.

comment:5 Changed 7 weeks ago by J. Max Mena

Fixed the typo and upped to r20543, and everything works as expected.

Is there anything more I should be checking?

(Going to hold on to this ticket for a little while longer regardless, I want to learn some more about what's going on)

comment:6 Changed 5 weeks ago by J. Max Mena

Resolution: fixed
Status: newclosed

I've played around with this a little further and think it's a fascinating add-on to the sharing system, but I don't have anything further to contribute to this ticket as I haven't found anything wrong, but it has been fun sending specific windows to specific clients.

Note: See TracTickets for help on using tickets.