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

Re: x11drv: don't consume Expose events when filter contains QS_PAINT
by Clinton Stimpson Oct. 10, 2007

Oct. 10, 2007

Clinton Stimpson wrote: > Fix for bug 9875 (There are more details in that bug report if you want). > Existance of update regions in the wine server correspond with WM_PAINT > existing in queue. Existance of Expose events in the X event queue don't > correspond with update regions in the wine server, which can result in a loss > of painting some regions. > > Don't consume Expose events when filtering with QS_PAINT. > Anything wrong with this patch? Thanks, Clinton Stimpson

2 1

Re: wined3d: Make sure GL context is created before binding FBO.
by Stefan Dösinger Oct. 10, 2007

Oct. 10, 2007

Am Dienstag, 9. Oktober 2007 04:18:29 schrieb Allan Tong: > This patch moves the call to ActivateContext ahead of the opengl > calls. This fixes a crash I was getting in the Bioshock demo where a > newly created thread was calling glBindFramebufferEXT before a > rendering context was established for the thread. The patch is correct in spirit, ActivateContext has to be called before other gl stuff is done, but I have found that it causes some problems for an unknown reason. So perhaps other bugfixes are needed before this works properly. One of the problems was a major rendering problem in half life 2 lost coast.

2 1

Request for "wine packages" bugzilla component
by Scott Ritchie Oct. 9, 2007

Oct. 9, 2007

Sometimes we have bugs directly related to our packaging. It would be nice to have a bugzilla component for them, and perhaps automatically subscribe the package maintainers. Thanks, Scott Ritchie

2 1

Fwd: Open source organizations particpating in Kerberos consortium?
by Dan Kegel Oct. 9, 2007

Oct. 9, 2007

Should Wine (represented by Kai?) participate in the Kerberos consortium? If we want to, the door's open... Stephen C. Buckley <sbuckley(a)mit.edu> wrote: >Dan Kegel wrote: >>Is the consortium open to participation by open >>source orgs like Wine and Samba? It might be useful... > >Absolutely! > >Stephen C. Buckley >Executive Director >MIT Kerberos Consortium >Massachusetts Institute of Technology >77 Massachusetts Ave W92-159 >Cambridge, MA 02139 > >email: sbuckley(a)mit.edu >web: http://www.kerberos.org

2 1

Re: comctl32: fixed drawing the trackbar background when themes are installed
by Frank Richter Oct. 9, 2007

Oct. 9, 2007

On 07.10.2007 17:41, Reece Dunn wrote: > The DPI trackbar has a black background that does not match the > property sheet background. > > This patch fixes this so that the trackbar is drawn correctly. Wouldn't, or so says my intuition, the parent background usually be drawn before the control background? -f.r.

2 1

OpenGL child windows (bug 2398, fixed!)
by Roderick Colenbrander Oct. 9, 2007

Oct. 9, 2007

Hi, Thanks to Chris his recent child window work, there is now support for OpenGL child windows in Wine. For the exact details read bug 2398 or Chris his patches. In short the patches use XComposite were possible and else X pixmaps. Not all drivers support both properly yet but for compiz/aiglx purposes most drivers are adding the needed support. I would say test the stuff and report problems. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

5 7

Wine Desktop Integration Code
by EA Durbin Oct. 9, 2007

Oct. 9, 2007

Out of curiousity, where can I find the code in the wine source that handles creation of the Menu entries in Gnome and KDE. _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

3 2

Re: [bugzilla] Upgrade from 3.0 to 3.0.2 .
by Alexandre Julliard Oct. 9, 2007

Oct. 9, 2007

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > --- > See http://www.bugzilla.org/releases/3.0.2/release-notes.html and > http://www.bugzilla.org/status/changes.html for information about > the changes. > --- > If this patch is rejected from inclusion, please tell me why, as > I would have to ask anyway. Now that we are using a git repository, upgrades should be done by importing the new version to the upstream branch and doing a git merge, instead of applying a patch directly to the master branch. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: PulseAudio as a sound output?
by King InuYasha Oct. 8, 2007

Oct. 8, 2007

On 10/8/07, King InuYasha <ngompa13(a)gmail.com> wrote: > > Wine must not let go of the OSS support since OSS was recently made GPL'd > and CDDL'd for use in FOSS kernels by its maker (4Front) and OSS is the > POSIX audio system of choice for nearly every time except Linux. Linux does > not use OSS anymore and uses ALSA. Since Linux is the primary target of > Wine, obviously ALSA needs to be well supported. Since under normal > conditions ALSA and OSS do horrible mixing and handling of audio (kernel or > audio module bug, whatever, its still a problem), I'm betting that was why > the ESD and JACK drivers were made. I am not disputing the JACK driver > because I recognize that JACK may be necessary for certain tasks. > > However, the ESD driver should be replaced with something more up to date. > I hope that PulseAudio would be that replacement. I don't think I suggested > removing the baseline stuff (ALSA and OSS). PulseAudio is what I would > consider to be the middle man between JACK and ALSA/OSS. Mainly because it > does have some of the upscale features (low-latency, network sound, etc.) > and some of the commodity features (superior mixing, multiple audio backend > support like ALSA, OSS, and Win32MM, etc.) I believe this balance would help > with Wine sound very much. > > Certainly the new scheduler in Linux kernel 2.6.23 would improve how the > kernel/kernel modules handle threading and processing the audio streams, but > that wouldn't necessarily help with the baser problems (mixing, stream > locks, etc.) though it does help with stuff like stuttering. I also > recognize that Alexandre may not want to support so many audio backends. I > find only three absolutely necessary, and the fourth one is widely clamored > for. The necessary ones are: JACK, OSS, and PulseAudio. The widely clamored > one is ALSA. Why? Because ALSA is ENTIRELY Linux specific. Wine is to be a > Win32 to UNIX translation layer for compiled applications. If too much focus > on being Linux-specific is given, I believe it will mess up general FOSS > adoption as a whole. > > Just my two cents.... :) > > On 10/8/07, Tijl Coosemans <tijl(a)ulyssis.org> wrote: > > > > On Monday 08 October 2007 14:43:30 Dave Phillips wrote: > > > Well, first I'd suggest simply supporting ALSA as thoroughly as > > > necessary or possible. It is the default kernel sound system, Wine > > > may as well incorporate it as well as it can. Supporting the > > > deprecated OSS API might be a good idea too, through ALSA's > > > OSS-compatibility layer. As one devel noted, it may be a good idea to > > > forego further development of things like the NAS and ESD servers > > > until a more solid basis exists for ALSA/OSS. > > > > I just wanted to add that OSS isn't deprecated. ALSA is Linux-only. > > OSS is a multiplatform solution. > > > > > > >

1 0

Wine's wikipedia article sucks
by Scott Ritchie Oct. 8, 2007

Oct. 8, 2007

The current article for Wine is here: http://en.wikipedia.org/wiki/Wine_%28software%29 It needs a lot of work. There's a large (and growing) todo list on the talk page: http://en.wikipedia.org/wiki/Talk:Wine_%28software%29 Some of the information needed (eg, statistics for Wine usage) are likely unavailable to the average wikipedian, so we Wine experts might need to help directly. I'm pretty sure a good wikipedia article, with proper links and explanations, would cut down significantly on the amount of user misinformation about Wine. Fixing the wikipedia article might do more for usability than actually improving the software. Thanks, Scott Ritchie

1 0