disabling "Modal windows" in tray needs re-initialize

[mviereck]

Related to #2255
Seen with xpra v3.0.8-r25889 and xpra v4.0-r25629 on Debian bullseye.

I have an application (kaptain) that sets the modal-windows flag and causes issues with keyboard and mouse focus.
Disabling modal windows fixes the issue.

I did not set --modal-windows=no, so I had to disable it in the xpra tray menu. But that does not fix the issue. I also have to re-initialize the windows using the tray menu. xpra should do that automatically.

Side note: Although I reported #2255 myself, I stumbled over the modal-windows issue again and it took me some time to figure out why the windows do not respond. For some days I used ssh -X instead of xpra because xpra was unusable.
It might be reasonable to set --modal-windows=no as a default because the solution for this issue is not obvious to users.

[Antoine Martin]

Done in r25928.

We've had problems with modal windows (#1895) in the past: #2270, #2304.
But by not honouring the modal window flag, we're likely to encounter other bugs...
The only way to avoid all these bugs is to only forward a single application per xpra session.

[mviereck]

Thank you!

Please note that I've also pointed on an xpra issue. Though, it might be obsolete now:

I had to disable [modal windows] in the xpra tray menu. But that does not fix the issue. I also have to re-initialize the windows using the tray menu. xpra should do that automatically.

Only disabling "Modal Windows" in the tray menu was not enough. xpra should automatically re-initialize the windows.

[stdedos]

Replying to Antoine Martin:

The only way to avoid all these bugs is to only forward a single application per xpra session.

I would like to see how would that work in the future.

Maybe you could have a session that's not bound by screens (and instead is bound on some string), and then xpra could use >:2000 displays to host windows as-requested?

... but then you don't know which processes will spawn windows to split them