wine-devel December 2009

wine-devel@winehq.org

96 participants
251 discussions

Re: shdocvw: Added support for non-english IE MUI
by Paul Vriens 08 Dec '09

08 Dec '09

On 12/08/2009 11:10 AM, Alistair Leslie-Hughes wrote: > Hi, > When IE has support to display non-english menus, its returns a > translated string for the control name (get_Name) for the language being > used. > > > Changelog: > shdocvw: Added support for non-english IE MUI > > Best Regards > Alistair Leslie-Hughes > Hi Alistair, Although I can agree on adding this language support to the implementation, I'm not sure we want this in the tests. Someone has to keep the translations up-to-date in the tests. Next to that the new tests assume that our translation is exactly the same as Windows, not sure if we even want that. -- Cheers, Paul.

2 1

winetest + pbuffer + nvidia 190.18 drivers = X crash
by Austin English 08 Dec '09

08 Dec '09

Been happening for a few days...not sure what triggered it, but when coming back from work I see my login screen, which explains the lack of 64-bit tests/appinstall results. I don't know if any of the D3D guys could take a look, but I'd appreciate it... -- -Austin

2 4

Re: [PATCH] user32: Make DefWindowProc handle SHIFT+F10.
by Dmitry Timoshkov 08 Dec '09

08 Dec '09

"Kusanagi Kouichi" <slash(a)ac.auone-net.jp> wrote: > According to MSDN[1], DefWindowProc generates the WM_CONTEXTMENU > message when SHIFT+F10 is typed. > > [1] http://msdn.microsoft.com/en-us/library/ms647592.aspx Usually MSDN statements/descriptions shouldn't be taken as an action guide, a test case is required to see what happens in reality. At least a quick test shows that if a menu is activated pressing Shift+F10 does nothing. dlls/user32/tests/msg.c already has some tests for VK_APPS and VK_F10 press/release, please add a new test there. -- Dmitry.

1 0

Very long printernames and test failures
by Paul Vriens 08 Dec '09

08 Dec '09

Hi Detlef, Some test failures are shown on boxes with long printernames, for example: http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_… http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/win7_1… And indeed if I create a local printer with a very long name the cutoff is one bigger than what the test is currently doing. The attached patch fixes that. I don't think this is enough though. Our implementation cuts of at '-1' from the looks of it. The best test would probably to add a printer in the tests and check for the size of the name in the strcut but I don't know how easy/intrusive that is. Any thoughts? -- Cheers, Paul.

2 3

Free VMware Workstation licenses for Wine developers
by Greg Geldorp 08 Dec '09

08 Dec '09

I already announced this at WineConf, but for people who were not there: VMware wants to support the Wine project by providing free of charge Workstation 7 licenses to Wine developers. We're not going to be too picky about the definition of "Wine developer". If you have been able to get a patch past Alexandre you've shown enough dedication to qualify ;-). There are a few restrictions on these licenses: - Not for resale - Not upgradable - No support entitlement If you want a license, just send me an email (off-list). Ge.

1 0

How does --with-wine64 work?
by Austin English 08 Dec '09

08 Dec '09

Vincent asked me to get add a --with-wine64 option to my build script. I was testing around, and can't seem to get it to work: $ mkdir - p $HOME/wine{32,64} $ cd $HOME/wine64 $ ~/wine-git/configure --enable-win64 $ make -j4 $ cd $HOME/wine32 $ ~/wine-git/configure --with-wine64=~/wine64 ... > checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/ ~/wine-git/configure --with-wine64=~/wine64/tools/ ... checking for the directory containing the Wine tools... configure: error: could not find Wine tools in ~/wine64/tools/ What am I missing? Perhaps it needs to be installed somewhere first? -- -Austin

3 4

wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
by Peter Kovacs 08 Dec '09

08 Dec '09

Hi there, I want to bring this Issue up in Development Mailinglist. This proplem is about a bug that cant be fixed within wine, and The Bugtracker doesnt help it. I think this Bug is at the moment an Epic Fail of Open Source Development. (And needs to be solved so we get a accepted Fix somewhere someday) The Bug is Deadlocked. The Problem is in this Bug roughly spoken that in some games the Mouse movement is captured and not the real position. Now X only returns the real position. This Bug is a dependance of X (If I got it right). Since this Bug appeared people worked around this Bug by improving dirty hacks (by calculating mouse movement using weird? code), and maintaining them. And when Possible to make them switchable. Now Vitaliy Margolen actively stopped the maintenance of this workarounds (in the bug called dirty hacks.), by marking the patches obsolete and changing title. The Bug exist since 2009 - 12 - 06. And has a long thread. I understand the move of Margolen here. For that you need to look at the Bug history (clicky: http://bugs.winehq.org/show_bug.cgi?id=6971). And I dont put blame on his move. But for this Bug wine needs another political solution. Just stopping people to write hacks, dirty or not will stop people reaching in more and more patches. This sole incident wont have an effect on hole development but most bugs I followed started with a dirty hack. And this is definitely giving the wrong impression on wine. What I want to say, Margolens move might be technical right, but is political pretty lame. Atm I don't see any ability that the bug will be proper fixed. 1) I Xorg may implement the Problem or may not. Maybe they are even not aware(? - Haven't took a look) The Bug-tracking in wine does not contain a Link to the Bug-tracking in Xorg. 2) I am betting wine - Dev has no one working on the Bug actively. So how can we get a proper Fix or point people towards proper fixes? Is it right to have no Dirty Hack solution which just works? Do you think by stopping Hacks you will encourage development in what (you) think is the right solution? Where is the Xorg Link for this Problem since it is a problem interesting wine but maybe not Xorg? Before anyone asks, I don't have the Time to solve this Bug. Nor I do believe does any one of the "dirty" hackers. Or they had done it Proper by now. Thanks Listening, hope you got the Problem I want to address. I am not on the list since I develop nothing for wine. I would it appreciate it a lot, if I could stay with the discussion by keeping my email address in CC Regards Peter

5 6

Wine sound discussion summary
by Stefan Dösinger 07 Dec '09

07 Dec '09

Hi, For those who didn't follow the big dsound argument thread, here is a quick summary of the main points. I originally inteded this as a summary mail, but while collecting the arguments I have instead taken the discussion off-list accidentally. But here's the current state: Pretty much everyone agrees that the current sound infrastructure is broken. In terms of how to fix it, there are 3 points to be worked out. 1) Use OpenAL or a more sophisticated driver infrastructure 2) If no OpenAL, what do we use 3) How do we get there. I'll mostly focus on (1) here, as the others depend on the decision of (1). On Wineconf we decided to give killing our entire sound infrastructure a try and replace it with a winmm and dsound based on OpenAL. That wasn't a promise by Alexandre to commit it, more an investigative study. The advantages of that would be: * A compact Wine sound system, we don't have many different sound drivers. OpenAL is available on all operating systems * We can let Linux(dmix, pulseaudio) do some or all of the mixing(with openal.so improvements) * Outsource workarounds for Alsa/PulseAudio/Coreaudio bugs to openal * Supporting DirectSound 3D is easy - openal just has it available. No need to reinvent the wheel. There are still a lot of dsound 3d games from WinXP and earlier. * Hardware accelerated 3D sound is possible. Currently there are no Linux drivers for that though. * Winmm, dsound and Windows openal.dll interaction still works fine as long as all libs interact with openal in the same way Disadvantages: * We have less control over our sound infrastructure and might get into troubles if some apps depend on the underlying driver system * We depend on the system openal. Linux distros have to keep their 32 bit openal updated. Getting bugfixes shipped to users might take years. MacOS OpenAL seems pretty broken. * Outsourcing bug workarounds is a slippery slope. It will be hard or impossible to work around problems without openal and distro help(and we need help again to get them fixed properly). * OpenAL is essentially just an abstraction layer not any system's native way to do sound. * Dsound 3D is dead in Win7, maybe we shouldn't focus our design decision on it 2) If no OpenAL, what do we use The consensus is mostly that if we don't use OpenAL for abstraction then we would aim for the Windows 7 sound driver API, or something very close to it. The goodies include a) Its the way Windows does it. b) If Win7 has user space audio driver support we might be able to use those drivers c) Technically native dsound and winmm might work, which can be helpful for debugging d) No bad surprises when apps start screwing around with the internals(e.g. load an DRM decryption APO into the sound processing chain). Problems of this sound infrastructure include: * It is very complex and maybe a lot more than we need. * The Windows 7 sound model mandates software mixing. We'd have a audiodg.exe process running that mixes all streams from all processes. Add in pulseaudio or dmix, and maybe dsound has to do its own mixing and you have 3 software mixers in a chain. But maybe that's a place where we can deviate from the MS design, or use mixing plugins provided by our drivers. * It rules out hardware accelerated dsound3d. Although a user might install Creative's openal wrapper or similar software to get back HW dsound 3D in the windows 7 way, with all its pros and cons. Most new 3D sound games use openal natively. * For full compatibility to drivers and native libs we'd need the DDK, and nobody checked the license terms so far. 3) How do we get there. This obviously depends on what we do, and we probably won't do much before the 1.2 release. For the OpenAL way, we could just throw in the code Maarten wrote so far, or Chris' Dsound->OpenAL wrapper. For Win7, one idea was to implement one more Win 3.1 sound driver in Wine that is based on the Win7 infrastructure, then implement that infrastructure and move winmm and dsound over. Once this is done, throw out the old Win 3.1 stuff. Or implement the Win7 infrastructure and maintain a separate dsound and winmm off-tree(developed on Windows), and put them in place once the Win7 driver infrastructure in Wine is solid enough.

7 15

Re: 2/2 WGL: move some traces to winediag
by Henri Verbeet 07 Dec '09

07 Dec '09

2009/12/7 Roderick Colenbrander <thunderbird2k(a)gmail.com>: > Use this version instead. The last version contained some updates to > the wined3d winediag patch. > Sending this to winediag does mean it won't show up in +wgl traces anymore. Do we want that?

2 1

Please Review - Revised OS X Application Bundle patch
by Joerg-Cyril.Hoehle＠t-systems.com 07 Dec '09

07 Dec '09

Hi, + * NOTES: An Application Bundle generally has the following layout + * + * foo.app/Contents + * foo.app/Contents/Info.plist + * foo.app/Contents/MacOS/foo (can be script or real binary) + * foo.app/Contents/Resources/appIcon.icns (Apple Icon format) + * foo.app/Contents/Resources/English.lproj/infoPlist.strings + * foo.app/Contents/Resources/English.lproj/MainMenu.nib (Menu Layout) Could you please comment on why you think that using a .app is the right approach? (please explain the goal: provide desktop icons?) What do you plan to put into that bundle? What would the menu be? (Is there one at all?) As an alternative, I've been creating .command files, as explained in the FAQ http://wiki.winehq.org/MacOSX/FAQs They seem conceptually simpler yet provide what you'll find in the xyz.desktop file that Wine produces on Linux: - Icon - Terminal window that shows Wine's log and I/O from application. Where does such output go in the .app case? - file name - Change Directory to app's directory (or any other) It does not depend on wine start /unix Isn't that missing from your patch: + fprintf(file, "#!/bin/sh\n"); + fprintf(file, "WINEPREFIX=\"%s\" wine \"%s\" %s\n\n", + wine_get_config_dir(), path, args); This information is present in the .desktop files - Move the icon anywhere you like and click to start it. There's no dependency on Applications/ or any other setting. - Easily modified by the user to change WINEPREFIX, add WINEDEBUG or whatever -- if needed at all. You'll remember that I presented my approach on 2009-09-14 in this list. I was wondering whether Wine should create such xyz.command files on MacOS instead of the xyz.desktop ones. They are so close to each other. Perhaps it is precisely that additional Terminal.app window that you or other Mac users might dislike? (I've not investigated whether there are "hide" or "auto-close on exit" properties that could be set.) Regards, Jörg Höhle

3 9

← Newer
1
...
17
18
19
20
21
22
23
...
26
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2009