Re: [GSoC] My proposal for GSoC 2013
On Wed, Mar 20, 2013 at 11:35 AM, Gediminas Jakutis 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 :). -- -Austin
Re: winemac: Implement GetDeviceGammaRamp() and SetDeviceGammaRamp().
On Mar 20, 2013, at 1:33 PM, André Hentschel wrote: > Am 18.03.2013 04:41, schrieb Ken Thomases: >> --- >> dlls/winemac.drv/display.c | 131 >> >> dlls/winemac.drv/gdi.c |4 +- >> dlls/winemac.drv/macdrv.h |2 + >> 3 files changed, 135 insertions(+), 2 deletions(-) > > Hi, > wrt macdrv_SetDeviceGammaRamp, the X11 driver has some validation in > xvidmode.c->ComputeGammaFromRamp() because windows doesn't allow every ramp. > It might happen that apps try bad ramps and the screen simply gets dark > without validation. Ah, interesting. I missed that. > I'll see if i can copy/move the validation to gdi32 where the driver function > normally get's called so that the validation is driver independent. Thanks! -Ken
Re: [GSoC] My proposal for GSoC 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.
[GSoC] My proposal for GSoC 2013
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
Re: winemac: Implement GetDeviceGammaRamp() and SetDeviceGammaRamp().
Am 18.03.2013 04:41, schrieb Ken Thomases: > --- > dlls/winemac.drv/display.c | 131 > dlls/winemac.drv/gdi.c |4 +- > dlls/winemac.drv/macdrv.h |2 + > 3 files changed, 135 insertions(+), 2 deletions(-) Hi, wrt macdrv_SetDeviceGammaRamp, the X11 driver has some validation in xvidmode.c->ComputeGammaFromRamp() because windows doesn't allow every ramp. It might happen that apps try bad ramps and the screen simply gets dark without validation. I'll see if i can copy/move the validation to gdi32 where the driver function normally get's called so that the validation is driver independent. -- Best Regards, André Hentschel
Re: [PATCH 2/2] msvcrt: Fixed fgetwc behavior on multibyte characters and unicode files
On 03/20/13 09:41, Akihiro Sagawa wrote:
On Mon, 18 Mar 2013 17:11:04 +0100, Piotr Caban wrote:
+char mbs[2];
This should be a constant, like MSVCRT_MB_LEN_MAX.
+int len = 0;
+ch = MSVCRT_fgetc(file);
+if(ch != MSVCRT_EOF) {
+mbs[0] = (char)ch;
+if(MSVCRT_isleadbyte(mbs[0])) {
This doesn't work correctly if char is signed. Because _isleadbyte()
expects the value of unsigned char or EOF as well as other is- functions.
I wrote some fgetwc() tests. Please refer following page:
https://testbot.winehq.org/JobDetails.pl?Key=24806
I've sent a fixed version. Thank you.
Thanks,
Piotr
Re: [PATCH 2/2] msvcrt: Fixed fgetwc behavior on multibyte characters and unicode files
On Mon, 18 Mar 2013 17:11:04 +0100, Piotr Caban wrote:
> +char mbs[2];
This should be a constant, like MSVCRT_MB_LEN_MAX.
> +int len = 0;
> +ch = MSVCRT_fgetc(file);
> +if(ch != MSVCRT_EOF) {
> +mbs[0] = (char)ch;
> +if(MSVCRT_isleadbyte(mbs[0])) {
This doesn't work correctly if char is signed. Because _isleadbyte()
expects the value of unsigned char or EOF as well as other is- functions.
I wrote some fgetwc() tests. Please refer following page:
https://testbot.winehq.org/JobDetails.pl?Key=24806
Akihiro Sagawa
Re: [7/10] winemenubuilder: Create a basic Info.plist.
On Tue, Mar 19, 2013 at 5:57 AM, Ken Thomases wrote: > On Mar 17, 2013, at 12:18 PM, Per Johansson wrote: > >> +namestr = CFStringCreateWithCString(NULL, link_name, >> CFStringGetSystemEncoding()); > > You should use CFStringCreateWithFileSystemRepresentation() to create > CFStrings from POSIX path strings. Fixed. Thanks, -- Per Johansson
