March 2013 - Wine-Devel - list.winehq.org

Re: [GSoC] My proposal for GSoC 2013

by Vincent Povirk

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.

March 20, 2013

[GSoC] My proposal for GSoC 2013

by Gediminas Jakutis

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

March 20, 2013

Re: winemac: Implement GetDeviceGammaRamp() and SetDeviceGammaRamp().

by André Hentschel

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

March 20, 2013

Re: [PATCH 2/2] msvcrt: Fixed fgetwc behavior on multibyte characters and unicode files

by Piotr Caban

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

March 20, 2013

Re: [PATCH 2/2] msvcrt: Fixed fgetwc behavior on multibyte characters and unicode files

by Akihiro Sagawa

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

March 20, 2013

Re: [7/10] winemenubuilder: Create a basic Info.plist.

by Per Johansson

On Tue, Mar 19, 2013 at 5:57 AM, Ken Thomases <ken(a)codeweavers.com> 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

March 20, 2013

Re: Mac driver status: ready for contributions

by Ken Thomases

On Mar 19, 2013, at 1:31 AM, Charles Davis wrote: > I have one more of my own to add: > > * Fix crash whenever an app makes a GLU call. Ah, yes, I forgot that one. Thanks for reminding me. > I suspect this is because Mesa's GLU calls Mesa's libGL--which crashes horribly because there's no Mesa/GLX context current. Yes, basically. > I see two ways to fix that. One is to make GLU dispatch go through the driver. This is what I did for CrossOver 12. The problem is that it introduced a requirement that a WGL context be current on the thread to find the driver functions. (Technically, the GLU spec requires a current GL context at the time of any GLU calls, but glu32 doesn't require that and, empirically, it seems that Mesa's library doesn't either. Because some stuff that used to work was broken by CrossOver 12.) > The other is to actually implement glu32 (i.e. not as a forwarder to the system GLU). I'm not sure how AJ will feel about the first one--and I probably won't know until next week. Not thrilled, although willing to entertain it if it can be done in a relatively elegant and robust way. None of my proposals rose to those standards. ;) > The second one... writing a GLU is a lot of work. We could use SGI's (as Mesa does), but SGI GLU is largely written in C++--and I *know* AJ won't like that. Implementing glu32 on top of opengl32 was Alexandre's approach. He was looking for an open-source GLU implementation to use. He could find C implementations for most parts of GLU except the NURBS stuff. We didn't really get any further than that. -Ken

March 19, 2013

Re: Mac driver status: ready for contributions

by Charles Davis

I have one more of my own to add: * Fix crash whenever an app makes a GLU call. I suspect this is because Mesa's GLU calls Mesa's libGL--which crashes horribly because there's no Mesa/GLX context current. I see two ways to fix that. One is to make GLU dispatch go through the driver. The other is to actually implement glu32 (i.e. not as a forwarder to the system GLU). I'm not sure how AJ will feel about the first one--and I probably won't know until next week. The second one... writing a GLU is a lot of work. We could use SGI's (as Mesa does), but SGI GLU is largely written in C++--and I *know* AJ won't like that. There's probably something I'm missing here, though. I'd be happy to have that pointed out to me. Chip

March 19, 2013

Re: [10/10] winemenubuilder: Put appbundle icon inside the bundle.

by Ken Thomases

On Mar 17, 2013, at 12:18 PM, Per Johansson wrote: > + CFStringRef iconstr = CFStringCreateWithCString(NULL, icon, CFStringGetSystemEncoding()); Another place to use CFStringCreateWithFileSystemRepresentation(). -Ken

March 19, 2013

Re: [7/10] winemenubuilder: Create a basic Info.plist.

by Ken Thomases

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. > + pathstr = CFStringCreateWithCString(NULL, path, CFStringGetSystemEncoding()); Same thing here. > + data = CFPropertyListCreateData(NULL, propertyList, format, 0, &err); Since you don't use "err", just pass NULL. -Ken

March 19, 2013