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.
work in progress: control commands, inject x11 filters, etc
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)
xpra start :100 --start=xterm
xpra control :100 add-window-filter x11:window WM_CLASS = xtermXTerm '1'
XPRA_USER_UUID=1 xpra attach --sharing=yes
(the xterm should show up)
XPRA_USER_UUID=2 xpra attach --sharing=yes
(the xterm should not show up)
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':
(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)
xpra control :100 add-window-filter x11:window _NET_WM_NAME = Bar '1'
(only on client 1 - but not recursive this time, so the popup window will show on both clients!)
xpra control :100 add-window-filter x11:window WM_CLASS = "xtermXTerm" 'DISABLED'
xpra control :100 add-window-filter window pid = `pidof xterm` "1"
xpra control :100 remove-window-filters
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:
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"
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.
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?
Is there anything overtly wrong with what I ran?
Yes. You have a typo, it's
r20543 adds "-d filters" debug to make these errors easier to debug.
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)
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1934