August 2007 - Wine-Devel - list.winehq.org

Re: WGL: GDI support is not advertised with double buffering

by Roderick Colenbrander

Err, the patch is correct. I somehow missed that a test was part of it. Sorry. On Tuesday 14 August 2007 11:08, Roderick Colenbrander wrote: > Wouldn't it be cleaner to cache the double buffering property in the > WineGLPIxelFormat and set the gdi cap in there? That would skip another > unneeded function. > > Roderick

Aug. 14, 2007

Re: user32: LB_SETITEMDATA should return 1 on success, not 0

by Peter Verthez

On Tue, 2007-08-14 at 13:39 +0200, Alexandre Julliard wrote: > Peter Verthez <peter.verthez(a)advalvas.be> writes: > > > diff --git a/include/winuser.h b/include/winuser.h > > index 4297a8d..97363e0 100644 > > --- a/include/winuser.h > > +++ b/include/winuser.h > > @@ -2428,6 +2428,7 @@ typedef struct tagSCROLLBARINFO > > > > /* Listbox message return values */ > > #define LB_OKAY 0 > > +#define LB_SETITEMDATA_OKAY 1 /* undoc. OK return for LB_SETITEMDATA */ > > Please don't invent constants that don't exist on Windows. In this > case TRUE would work just as well. > Thanks, I've resubmitted the patch. For your information, this fixes a problem with the MapSource application (from Garmin) given in this bug comment: http://bugs.winehq.org/show_bug.cgi?id=4633#c2 With the patch, the AFX_COMBOBOX.HPP error doesn't occur anymore (apparently, the application checks the return value of LB_SETITEMDATA). Best regards, Peter.

Aug. 14, 2007

Re: [d3d8/tests] Make tests run again on win95

by James Hawkins

On 8/14/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > James Hawkins wrote: > > On 8/14/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > >> Hi, > >> > >> Again only to avoid a pop-up. Didn't fix/test the actual tests. > >> > >> Changelog > >> Make tests run again on win95 > >> > > > > Please change the subject of your emails to match the dll that you're > > patching. As it stands, it looks like you're patching advapi32 5 > > times, and we have to dig into the patch to see what dll you're > > actually changing. > > > But doesn't the subject show 'd3d8' for you? > Hmm, it doesn't show that, but I checked on pipermail and that is the case, so this is an issue with gmail. Sorry about the noise. -- James Hawkins

Aug. 14, 2007

Re: [d3d8/tests] Make tests run again on win95

by Paul Vriens

James Hawkins wrote: > On 8/14/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >> Hi, >> >> Again only to avoid a pop-up. Didn't fix/test the actual tests. >> >> Changelog >> Make tests run again on win95 >> > > Please change the subject of your emails to match the dll that you're > patching. As it stands, it looks like you're patching advapi32 5 > times, and we have to dig into the patch to see what dll you're > actually changing. > But doesn't the subject show 'd3d8' for you? Paul.

Aug. 14, 2007

Re: Font problem + patch solution

by Alexandre Julliard

penna(a)bb.com.br writes: > There is a patch proposed at the bug #7571 (http://bugs.winehq.org/show_bug.cgi?id=7571) > It works very well and I did not experiment any regression. Maybe > it is not the ideal patch and if it is not, maybe we can provide a fix for > that. However, at least it fixes the font problem and did not introduce > any undesirable efects. > Is that possible to apply that patch at the main tree? Comments > are also welcome! You should provide test cases that show that your patch is correct. -- Alexandre Julliard julliard(a)winehq.org

Aug. 14, 2007

Re: [d3d8/tests] Make tests run again on win95

by James Hawkins

On 8/14/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Again only to avoid a pop-up. Didn't fix/test the actual tests. > > Changelog > Make tests run again on win95 > Please change the subject of your emails to match the dll that you're patching. As it stands, it looks like you're patching advapi32 5 times, and we have to dig into the patch to see what dll you're actually changing. -- James Hawkins

Aug. 14, 2007

Re: Problems with focus losing on virtual desktops

by Jesse Allen

On 8/14/07, Christian Authmann <spam(a)authmann.de> wrote: > > > Moving the virtual desktop window with Hotkey+drag: lost focus. > I've noticed that kwin seems to contribute to this. Hotkey-dragging a > xev-window leads to these entries (keypress-events removed): > > -- snip -- > > now the additional FocusOut/FocusIn seems weird and may well be a kwin > bug that leads to this issues. Again, wine handles this good on regular > windows, but bad inside a virtual desktop. > > After closing the opened app so that the virtual desktop (or xev in this > case) receives focus again, it'll get a simple FocusIn event, which > activates the virtual desktop window, but deactivates the application > window inside. This problem sounds similar to bug 9301 (resolved WONTFIX). Look here for reasons. http://bugs.winehq.org/show_bug.cgi?id=9301

Aug. 14, 2007

Re: Problems with focus losing on virtual desktops

by Jesse Allen

On 8/14/07, Christian Authmann <spam(a)authmann.de> wrote: > Jesse Allen schrieb: > > > I don't have much to comment on this one other than if you can prove > > that this is not a behavior in windows, then you should probably open > > a bug report. > > I don't even know if it's a wine bug, it might as well be d2, the window > manager or a windows design issue. > It works fine when explorer.exe is present in wine (i.e. virtual desktop > mode) but fails when it's not. I never checked what happens to d2 in > windows when explorer.exe isn't there. And I don't feel like wasting a > day to get a working windows installation which allows me to kill explorer. > It's really not an issue, virtual desktop mode is superior to diablo's > window mode anyway: diablo defaults to slow and ugly direct2d rendering > when started with -w. > > Hence no bug report. Oh that's right. That's another reason why the window option from the game is pretty much a "hack"; it only allows ddraw mode. > >> b) Using d2 in fullscreen mode inside wine's virtual desktop: d2 will ... > > > > This problem sounds like is caused by the design of the game. We can't fix this. > > How is this the game's fault? > Of course, minimizing on losing focus is the game's fault/feature, but > thinking that the focus has been lost when it clearly hasn't (or the > other way round) is a bug. Something has to tell the game "you lost > focus". These problems didn't happen in older wine versions (even 0.9.2x > where focus losing was possible) and don't happen on windows. Windows doesn't have virtual desktop. > > I've just tested with a different application inside a virtual desktop, > watching the window title to see if it's active or not. In short: This > broken focus behaviour on virtual desktops isn't limited to d2. Which application is this? > > > Moving the virtual desktop window with Hotkey+drag: lost focus. > I've noticed that kwin seems to contribute to this. Hotkey-dragging a > xev-window leads to these entries (keypress-events removed): > > -- snip -- > > now the additional FocusOut/FocusIn seems weird and may well be a kwin > bug that leads to this issues. Again, wine handles this good on regular > windows, but bad inside a virtual desktop. > > After closing the opened app so that the virtual desktop (or xev in this > case) receives focus again, it'll get a simple FocusIn event, which > activates the virtual desktop window, but deactivates the application > window inside. This seems correct behavior to me, if the wine windows are confined to the virtual desktop. But someone else can comment. > > > > This ALT key problem seems like the window manager is still > > intercepting the ALT key somehow (even though certain keystrokes are > > disabled). I'll test for this and tell you whether that's my > > conclusion. > > thank you. > I've tried testing with a couple of different window managers, but they > all had Alt+click bound to window moving, so I couldn't test. > Maybe it is KWin-specific (or specific to my configuration), but it'll > still only happen inside virtual desktops, never on native linux windows > or d2 outside a virtual desktop. > > Is there something like xev for windows I could use for further testing? Like I said, windows doesn't have "virtual desktop" Jesse

Aug. 14, 2007

Re: Problems with focus losing on virtual desktops

by L. Rahyen

On Tuesday August 14 2007 13:58, Christian Authmann wrote: > thank you. > I've tried testing with a couple of different window managers, but they > all had Alt+click bound to window moving, so I couldn't test. I see no problem here. Personally I use KDE and have Win+click combination to move windows. Go to Window menu (you can find it in any window) -> Configure Window Behavior -> Actions -> Window Actions -> Modifier key. You will have "Alt" there. Choose "Meta" instead and now you can use Win button instead of Alt. This is very useful because Alt+Click is very important in many Windows applications not only games but even in professional software like Maya or Lightwave.

Aug. 14, 2007

Re: Problems with focus losing on virtual desktops

by Christian Authmann

Jesse Allen schrieb: > I don't have much to comment on this one other than if you can prove > that this is not a behavior in windows, then you should probably open > a bug report. I don't even know if it's a wine bug, it might as well be d2, the window manager or a windows design issue. It works fine when explorer.exe is present in wine (i.e. virtual desktop mode) but fails when it's not. I never checked what happens to d2 in windows when explorer.exe isn't there. And I don't feel like wasting a day to get a working windows installation which allows me to kill explorer. It's really not an issue, virtual desktop mode is superior to diablo's window mode anyway: diablo defaults to slow and ugly direct2d rendering when started with -w. Hence no bug report. >> b) Using d2 in fullscreen mode inside wine's virtual desktop: d2 will >> sometimes think it lost focus, even if it didn't. >> Moving the wine window around with hotkey+drag: d2 minimizes. >> Moving the window by the title bar: nothing happens. (using kde/kwin btw) >> Sometimes just clicking inside the window while playing will cause d2 to >> minimize, although I haven't found a reproducible pattern (i.e. do I >> have to press certain keys, do I have to double-click, etc). >> >> Activating a different window outside the virtual desktop? d2 stays >> open. Or opening another application via hotkey, or pulling down yakuake >> via hotkey. It stays open. >> But, if I reactivate the virtual desktop window afterwards: d2 >> minimizes. Ouch. > > This problem sounds like is caused by the design of the game. We can't fix this. How is this the game's fault? Of course, minimizing on losing focus is the game's fault/feature, but thinking that the focus has been lost when it clearly hasn't (or the other way round) is a bug. Something has to tell the game "you lost focus". These problems didn't happen in older wine versions (even 0.9.2x where focus losing was possible) and don't happen on windows. I've just tested with a different application inside a virtual desktop, watching the window title to see if it's active or not. In short: This broken focus behaviour on virtual desktops isn't limited to d2. Moving the virtual desktop window with Hotkey+drag: lost focus. I've noticed that kwin seems to contribute to this. Hotkey-dragging a xev-window leads to these entries (keypress-events removed): -- snip -- FocusOut event, serial 31, synthetic NO, window 0x3000001, mode NotifyGrab, detail NotifyAncestor ConfigureNotify event, serial 32, synthetic YES, window 0x3000001, event 0x3000001, window 0x3000001, (1605,56), width 178, height 178, border_width 0, above 0x0, override NO [more of those while moving. Then, when letting go:] FocusIn event, serial 32, synthetic NO, window 0x3000001, mode NotifyUngrab, detail NotifyAncestor -- snap -- However, this should mean that the window inside the virtual desktop regains focus after the drag is complete, right? It doesn't. Opening (and activating) a different window: the windows program thinks it's still focused. Reactivating the virtual desktop window: the windows program loses focus. here's an xev dump of what xev receives when opening another window via hotkey while xev is active (the Super_L-Key is obviously part of my hotkey-combination). -- snip -- KeyPress event, serial 31, synthetic NO, window 0x3000001, root 0x1a5, subw 0x0, time 2684778, (738,830), root:(2343,873), state 0x10, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False FocusOut event, serial 31, synthetic NO, window 0x3000001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 31, synthetic NO, window 0x3000001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 31, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 64 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 31, synthetic NO, window 0x3000001, mode NotifyNormal, detail NotifyNonlinear -- snap -- now the additional FocusOut/FocusIn seems weird and may well be a kwin bug that leads to this issues. Again, wine handles this good on regular windows, but bad inside a virtual desktop. After closing the opened app so that the virtual desktop (or xev in this case) receives focus again, it'll get a simple FocusIn event, which activates the virtual desktop window, but deactivates the application window inside. > This ALT key problem seems like the window manager is still > intercepting the ALT key somehow (even though certain keystrokes are > disabled). I'll test for this and tell you whether that's my > conclusion. thank you. I've tried testing with a couple of different window managers, but they all had Alt+click bound to window moving, so I couldn't test. Maybe it is KWin-specific (or specific to my configuration), but it'll still only happen inside virtual desktops, never on native linux windows or d2 outside a virtual desktop. Is there something like xev for windows I could use for further testing? greetings, Tub

Aug. 14, 2007