[GSoC] My proposal for GSoC 2013
madewokherd at gmail.com
Wed Mar 20 15:26:37 CDT 2013
I think the reasons for the limitation on the virtual desktop setting
are more ideological than technical. It used to work the way you say,
but then Wine's desktop management was overhauled so that:
* Explorer.exe manages all desktop windows, including the virtual
desktop. I believe this is required for multiple processes to exist in
the same virtual desktop window.
* Wine's virtual desktops now use the window station/desktop API's
(which also exist on Windows). In theory, Windows programs can use
this to inspect all of the available desktops, interact with windows
on other desktops, and control the desktop window of child processes.
But it also means programs on different desktops are isolated from
each other unless they're programmed with desktops in mind.
* Processes inherit desktops from parent processes rather than
creating their own. This is technically necessary because of the
previous point about isolating desktops. If a program spawns a child
process that ends up in a different desktop, the child may not be able
to communicate with the parent, and you end up with a Wine bug.
You could perhaps argue that the concept of a virtual desktop window
and the win32 concept of a desktop should be separated, and it should
be possible for a process to exist in a separate desktop window while
being in the same win32 desktop as processes that exist in a root
window. That sort of thing can currently happen when Wine is run from
two different X sessions, such as a local desktop and remote X over
ssh. Taking steam and some fullscreen game as an example, some weird
things happen when the fullscreen game is on the same desktop as steam
but its windows are in a virtual desktop. For one, the two processes
don't see the same screen resolution. If the steam window gains focus,
the fullscreen game necessarily loses focus (because only one process
per desktop can be focused), and that may cause the fullscreen game to
attempt to minimize itself.
The challenge of making this work is to come up with a system that is
consistent, a correct implementation of the win32 api, enables the use
case you want while not breaking anything that works now, and can be
implemented cleanly. If you can manage all of those things, you can
probably get your change into Wine, but it's a really hard problem and
might not even be possible.
More information about the wine-devel