https://bugs.winehq.org/show_bug.cgi?id=51230
--- Comment #6 from subgraph93@gmail.com --- Scenario A: Two independent virtual desktops. I think all winecfg VD parameters are already stored in the registry as expected (and if I'm not mistaken, the program name is used as the VD name).
The option to provide a common virtual desktop for two programs via command line parameters is still present, for example
wine explorer /desktop=test,1024x768 notepad wine explorer /desktop=test,1024x768 winecfg
and because the name "test" is the same, winecfg launches in the same virtual desktop.
Scenario B: I think the actual behavior is that child processes of a process that uses a VD launch in the same VD. Example:
wine explorer /desktop=test,1024x768 wineconsole (then in the console) notepad
this will open notepad in the same virtual desktop.
Virtual desktop sizes were (and I believe should be) independent, you could have
wine explorer /desktop=test,1024x768 notepad wine explorer /desktop=test2,800x600 winecfg
and it would launch two virtual desktops with different sizes
--------
I believe you can set per-application settings in new (affected) versions and revert to an older (unaffected) version to see them work, which means the corresponding registry entries are stored as expected. I am not sure why it is being presented as if it were an intentional change.
"Automatically capture the mouse in full-screen windows" is another regressed aspect.
Another mitigation strategy could be to allow to set up all these options in command line parameters (like desktop, its name and size). Maybe some of them already exist as command line options (I only learned about /desktop relatively recently), but even if so, I don't know what they are.
So the way I see it, there are several separate issues here: 1) Regression: the settings winecfg stores in the registry per-application aren't respected since 6.5 2) It's impossible to use just winecfg to set up a common virtual desktop for two separately launched programs 3) It's impossible to use winecfg or just about anything to force a child process out of its parent's virtual desktop 4) For advanced use cases, it's not clear whether it's possible to provide all winecfg option equivalents via command line parameters. Maybe they exist, but aren't prominently documented, or maybe they are missing.
I believe the original issue reported (and the one I reported) is only [1]. [2] can be resolved with different launch commands, I personally don't know a use case for [3], and a use case for [4] could be a backup against issues like [1].