Hello!
My name is Gediminas Jakutis. I study Informatics Engineering [bachelor / undergraduate] at Kaunas University of Technology, second year. I wish to try out GSoC for the first time by helping to improve Wine. My primary programming language is C. I am self-taught in C, but I believe my knowledge is good enough. I am quite familiar with Wine - I use it and experiment with it for many years now. I am subscribed to and read wine-devel for more than a year. I browse through Wine's source code once in a while out of curiosity. Thus, I have some knowledge of its structure. Sadly, I have not written any patches for Wine yet. Mostly due to lack of confidence.
For GSoC, I am suggesting my own idea. In case this idea is not good, I am open to changing it, thinking of a new one, or adopting one. My idea: I have noticed that Wine's virtual desktop feature is very limited - if the first program on a prefix starts without a virtual desktop, all programs launched during the same session also start without a VD, disregarding any VD settings and/or requests with environment variables. And vice versa - if the first program starts inside a VD, all other programs in that sessions start in the VD. Often, this can be worked around by using separate Wine prefixes. Yet sometimes, this workaround is not possible. A good example: steam and games that only run properly in a VD. This forces the user to start steam in a VD and makes steam itself unusable while a game is running, especially if the game does not support the steam overlay. I would like to fix this limitation and make it possible to properly choose to run different programs on one prefix with or without a VD regardless what was chosen to programs already running in that prefix. I can already see this requiring changes in the winecfg utility, by the way. In case this turns out to be too easy of a project, I could implement some way to perform "alt-tabbing" between programs in a VD and/or an optional (enable-able in winecfg) rudimentary taskbar for changing/checking focus.
I am very excited about participating in GSoC. And even more excited about starting to contribute to Wine by writing patches! Regardless if I get accepted or not, I wish to make Wine better. Thus, expect me to start submitting patches in the future even if I do not get accepted. ;]
Sincerely, Gediminas Jakutis
---- LDK Varčiai www.varciai.lt
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.
On Wed, Mar 20, 2013 at 11:35 AM, Gediminas Jakutis gediminas@varciai.lt wrote:
Hello! For GSoC, I am suggesting my own idea. In case this idea is not good, I am open to changing it, thinking of a new one, or adopting one. My idea: I have noticed that Wine's virtual desktop feature is very limited - if the first program on a prefix starts without a virtual desktop, all programs launched during the same session also start without a VD, disregarding any VD settings and/or requests with environment variables. And vice versa - if the first program starts inside a VD, all other programs in that sessions start in the VD. Often, this can be worked around by using separate Wine prefixes. Yet sometimes, this workaround is not possible. A good example: steam and games that only run properly in a VD. This forces the user to start steam in a VD and makes steam itself unusable while a game is running, especially if the game does not support the steam overlay. I would like to fix this limitation and make it possible to properly choose to run different programs on one prefix with or without a VD regardless what was chosen to programs already running in that prefix. I can already see this requiring changes in the winecfg utility, by the way.
In addition to Vincent's comments, note that you _can_ set up virtual desktops for certain apps but not others within a single WINEPREFIX (though Steam may not like this, I haven't tried it myself).
There's a bit more info at http://wiki.winehq.org/FAQ#head-dba86ae589dca54a116a3fc21f6237af45e8119c.
This has been in Wine for quite a while...a significant part of Summer of Code is researching potential ideas before proposing them. Though you did start early, so you have plenty of time to find other ideas :).
Hello again! Thank You all for the feedback!
There's a bit more info at http://wiki.winehq.org/FAQ#head-dba86ae589dca54a116a3fc21f6237af45e8119c.
That's odd - I could've sworn this was an environment variable which had the same limitations as using winecfg! My memory must be playing tricks on me... And yes, now that I tested it again, I see it really does the job. Except for not working with steam games, but that is steam's fault, not Wine's.
Though you did start early, so you have plenty of time to find other ideas
Indeed... But now that I have to think of something else - what general areas in Wine are most welcome for GSoC ideas? I Looked over the GSoC Wine's wiki page, but I do not know how much I can trust it. That is because after GSoC 2012, it was only edited once. And the edit comment says:
remove some stuff that's done (still quite a bit of cleanup left)..
Thank You for Your time! Gediminas Jakutis
-- LDK Varčiai www.varciai.lt
-
Austin English -
Gediminas Jakutis -
Vincent Povirk