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

Re: Fonts (+liberation again...)

by mark cox

Louis, What about a wine-fonts package? That would avoid the gpl issue. On 13/08/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > > "Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > > > Of course this patch lacks checking for presence of liberation, and > > has ugly hard-coded path for the liberation-font, but that could be > > worked on later on. > > > > Simple question: Could something like this be included in the > > source, otherwise i'm not gonna spend any time improving it. Any > > hints welcomed. > > No, it can't be included, the fonts are GPL not LGPL, and you don't > want to silently insert them into the Wine binary packages. > > -- > Alexandre Julliard > julliard(a)winehq.org > > >

Aug. 13, 2007

Problem with dlls/winex11.drv/opengl.c, revision 1.104

by Chris Rankin

Hi, With the update of dlls/winex11.drv/opengl.c from revision 1.103 to 1.104, World of Warcraft no longer starts in OpenGL mode. WoW complains that my graphics card does not have "dual-TMU support". (I have a Radeon R200 with Mesa 7.1) Cheers, Chris ____________________________________________________ Which email service gives you unlimited storage? http://uk.mail.yahoo.com

Aug. 13, 2007

Re: WineD3D: add opengl 1.2/1.3 constanst to wined3d_gl.h

by Roderick Colenbrander

Skip this patch for now as it barely reduces the patch size. The real patch adds much, much more constants and that has to be merged in one go (or it can be done earlier if you want to have it behind the ifdef). Tell me what you prefer :) Roderick On Monday 13 August 2007 20:06, Roderick Colenbrander wrote: > Hi, > > Add opengl 1.2 / 1.3 constants to wined3d_gl.h because gl.h on windows is > still 1.1. Further the defines are behind an ifdef for now because most > linux headers do define them and haven't placed them behind some version > check. > > Once all changes are done the ifdef will be removed. I add it now to > prevent large patches. > > Regards, > Roderick Colenbrander

Aug. 13, 2007

Re: Problems with focus losing on virtual desktops

by Jesse Allen

On 8/13/07, Christian Authmann <spam(a)authmann.de> wrote: > Hi, > > after installing 0.9.42 I noticed some odd behavior when playing Diablo > 2. I did a git bisect and nailed it down to this patch: > > http://source.winehq.org/git/wine.git/?a=commit;h=d836a5062141dd42293ed044d… > > winex11drv: Correctly react to focus loss away from Wine. > > > I noticed the following changes: > > a) Using diablo 2's windowed mode: d2 will realize when it's losing > focus again (as it did somewhere around 0.9.2x). As far as I can tell, > this works reliable. > (That's not a good thing for diablo 2, since d2 will minimize on losing > focus and cannot be brought back to life afterwards. But that's a > different bug.) 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. But I do believe the windowed mode wasn't really how the game was intended to be played, just how the "-opengl" switch does nothing other than corrupt the games graphics (and doesn't even utilize opengl). These were more likely used in development and left in for archaic reasons (seeing that the game doesn't visibly advertise either). It's entirely possible that the messaging handler reacts very similarly to like when it's in a virtual desktop because the game was designed to be full screen. > > > >From now on, please read "Diablo 2 minimizes" as "Diablo 2 thinks it > lost focus". > > 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. > > > c) virtual desktop again: when holding ALT to show the dropped items, > then left clicking somewhere, d2 thinks that ALT has been released. This > makes it quite hard to pick up items. > This problem does not occur when using regular windowed mode or when > changing the hotkey to something different - as far as I can tell only > ALT in virtual desktop mode is affected. > Note that I don't have any hotkeys on Alt (or Alt+click), I bound window > dragging to the otherwised unused windows key. 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. > > > While the patch does as intended on regular windows, it's effects on > virtual desktop windows can only be described as weird. > > I don't know how virtual desktops are supposed to work. At least for d2, > it'd be useful if one application inside the virtual desktop always > keeps focused (or rather, is told it'd still be focused). > IMHO that's the purpose of virtual desktops: banning the apps inside a > container where they shouldn't be influenced by outside stuff, including > activating a different window. > Not losing focus is also more sensible when virtual desktops are used as > a way to ban fullscreen-apps into windows: most fullscreen applications > don't expect to lose focus and behave weird. > > However, even if you think of virtual desktops simply as a means to > group windows, it's currently broken: losing focus on reactivation is a > little late. > > > I have compiled the latest git version without this patch, and virtual > desktop mode works fine again, so it's really down to this single line > of code. > > I'm not far enough into the code to know any possible solution, but for > immediate results a simple > > if (inside a virtual desktop) > do old behaviour > else > do new behaviour > > should do the trick until a better solution is found. > I can't tell you if this will happen. But I can look at the game again, and give my advice.

Aug. 13, 2007

Problems with focus losing on virtual desktops

by Christian Authmann

Hi, after installing 0.9.42 I noticed some odd behavior when playing Diablo 2. I did a git bisect and nailed it down to this patch: http://source.winehq.org/git/wine.git/?a=commit;h=d836a5062141dd42293ed044d… winex11drv: Correctly react to focus loss away from Wine. I noticed the following changes: a) Using diablo 2's windowed mode: d2 will realize when it's losing focus again (as it did somewhere around 0.9.2x). As far as I can tell, this works reliable. (That's not a good thing for diablo 2, since d2 will minimize on losing focus and cannot be brought back to life afterwards. But that's a different bug.) >From now on, please read "Diablo 2 minimizes" as "Diablo 2 thinks it lost focus". 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. c) virtual desktop again: when holding ALT to show the dropped items, then left clicking somewhere, d2 thinks that ALT has been released. This makes it quite hard to pick up items. This problem does not occur when using regular windowed mode or when changing the hotkey to something different - as far as I can tell only ALT in virtual desktop mode is affected. Note that I don't have any hotkeys on Alt (or Alt+click), I bound window dragging to the otherwised unused windows key. While the patch does as intended on regular windows, it's effects on virtual desktop windows can only be described as weird. I don't know how virtual desktops are supposed to work. At least for d2, it'd be useful if one application inside the virtual desktop always keeps focused (or rather, is told it'd still be focused). IMHO that's the purpose of virtual desktops: banning the apps inside a container where they shouldn't be influenced by outside stuff, including activating a different window. Not losing focus is also more sensible when virtual desktops are used as a way to ban fullscreen-apps into windows: most fullscreen applications don't expect to lose focus and behave weird. However, even if you think of virtual desktops simply as a means to group windows, it's currently broken: losing focus on reactivation is a little late. I have compiled the latest git version without this patch, and virtual desktop mode works fine again, so it's really down to this single line of code. I'm not far enough into the code to know any possible solution, but for immediate results a simple if (inside a virtual desktop) do old behaviour else do new behaviour should do the trick until a better solution is found. greetings, Christian

Aug. 13, 2007

Re: [Winetest RFI] What do you want out of the test suite?

by Paul Vriens

Stefan Leichter wrote: > Am Monday 13 August 2007 13:28 schrieb Paul Vriens: >> Stefan Leichter wrote: >>> Am Friday 10 August 2007 12:15 schrieb Paul Vriens: >>>> Hi, >>>> >>>> I just want to get people's opinion(s) about the >>>> needs/requirements/whishes for both the conformance tests themselves >>>> (including winetest) as well as the webpages. >>>> >>>> I'll collect the information and will put it on the wiki. >>>> >>>> Cheers, >>>> >>>> Paul. >>> What about marking the "todo_wine" on the web page somehow? >>> >>> Bye Stefan >> Hi Stefan, >> >> todo_wine will only be present on a Wine testrun. Results for each test are >> available (including todo) when you hover over the single results. >> >> We can of course use a general 'todo' visualization but who do you like to >> see that? >> >> Or was you're idea to show todo_wine's in Windows results !? >> >> Cheers, >> >> Paul. > Some days ago i had an issue with an installer. I remembered that i had this > long time ago and that i wrote a test to document the difference and a patch > to fix the issue. Only the test was accepted not the patch. > > Having the todo_wine on the test result page might have saved me some time > digging through the ChangeLog files. So just the fact there is a todo_wine (or actually for every platform) should be enough? A bit like the 'skip' border? > > Also it someone is locking for something todo, he can look to the test results > and see the known issues. I don't thing all issues are all documented in > bugzilla. > > Bye Stefan > I'll have a look if it's visually good to look at. We already have a lot of coloring so maybe we should start looking at some other means of visualization. Cheers, Paul.

Aug. 13, 2007

Re: [Winetest RFI] What do you want out of the test suite?

by Stefan Leichter

Am Monday 13 August 2007 13:28 schrieb Paul Vriens: > Stefan Leichter wrote: > > Am Friday 10 August 2007 12:15 schrieb Paul Vriens: > >> Hi, > >> > >> I just want to get people's opinion(s) about the > >> needs/requirements/whishes for both the conformance tests themselves > >> (including winetest) as well as the webpages. > >> > >> I'll collect the information and will put it on the wiki. > >> > >> Cheers, > >> > >> Paul. > > > > What about marking the "todo_wine" on the web page somehow? > > > > Bye Stefan > > Hi Stefan, > > todo_wine will only be present on a Wine testrun. Results for each test are > available (including todo) when you hover over the single results. > > We can of course use a general 'todo' visualization but who do you like to > see that? > > Or was you're idea to show todo_wine's in Windows results !? > > Cheers, > > Paul. Some days ago i had an issue with an installer. I remembered that i had this long time ago and that i wrote a test to document the difference and a patch to fix the issue. Only the test was accepted not the patch. Having the todo_wine on the test result page might have saved me some time digging through the ChangeLog files. Also it someone is locking for something todo, he can look to the test results and see the known issues. I don't thing all issues are all documented in bugzilla. Bye Stefan

Aug. 13, 2007

Re: [winetest] Show missing tests in single/group results

by Robert Kim Wireless Internet Advisor

Jakob, Paul, we should have a regular site for uploading screenshots like these... so that google can find them too... On 8/6/07, Jakob Eriksson <jakob(a)vmlinux.org> wrote: > Paul Vriens wrote: > > > > Comments/remarks etc.. are welcome. > > It is excellent that you are doing this, the reports are clearer for it. > I will try to submit test results regularly. > > > > regards, > Jakob Eriksson > > > > > -- Robert Q Kim, Wireless Internet Provider http://evdo-coverage.com/satellite-wireless-internet.html http://iptv-coverage.com http://wimax-coverage.com http://znitch.com unpaid overtime 2611 S. Pacific Coast Highway 101 Suite 203 Cardiff by the Sea, CA 92007 206 984 0880

Aug. 13, 2007

Re: [winetest] Show missing tests in single/group results

by Ferenc Wagner

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > 'http://www.xs4all.nl/~pvriens/200708031000.new.single/' shows the new results > page for single tests. Instead of a single '.' there is a failure shown (red > box) and a skip border (as these tests have not run). There is still a '.' which > could maybe better be a '?'. There is also a 'onMouseOver' hint when you go over > the '.'. Hi Paul, Sorry for being so late. As a quick note, onMouseOver should contain JavaScript code, not a freeform string. Isn't the title attribute enough? -- Regards, Feri.

Aug. 13, 2007

Re: wined3d: Activate context before applying fbo state.

by H. Verbeet

On 13/08/07, Vitaliy Margolen <wine-patches(a)kievinfo.com> wrote: > Fixes bugs 9293 and 9269. > --- > dlls/wined3d/device.c | 7 ++----- > 1 files changed, 2 insertions(+), 5 deletions(-) > Looks ok to me, fwiw.

Aug. 13, 2007