wine-devel June 2009

wine-devel@winehq.org

145 participants
318 discussions

Re: [2/5] libwine: Add a generic red-black tree.
by Alexandre Julliard 02 Jun '09

02 Jun '09

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > +void wine_rb_init(struct wine_rb_tree *tree, wine_rb_compare_func_t *compare) > +{ > + tree->compare = compare; > + tree->root = NULL; > + tree->stack.entries = malloc(16 * sizeof(*tree->stack.entries)); > + if (!tree->stack.entries) > + { > + ERR("Failed to allocate stack memory.\n"); > + } You can't hardcode malloc(), the allocator needs to be configurable, particularly for use from the memory management code. Also printing an ERR in that sort of code is not acceptable, errors need to be propagated correctly and handled by the user. I also still think this would be better as inline functions, at least until it stabilizes. We don't want to change the libwine interface any more than strictly necessary. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [ole32/tests] Fix a crash on NT4
by Paul Vriens 02 Jun '09

02 Jun '09

Paul Vriens wrote: > Changelog > Fix a crash on NT4 > Please don't use this one. I will soon sent a few others to replace this one. -- Cheers, Paul.

1 0

Re: gdiplus: add support for string alignment to GdipDrawString (try 2)
by Stephan Rose 02 Jun '09

02 Jun '09

>(reply didn't go to list as I expected, grr..) > >> Naw, it should still work normally. I've done aligned & rotated text under >windows before with DrawTextW, you still pass the rect like you would if it >wasn't rotated and set the alignment flags. The world transform should take >care of getting it all rotated to where it is supposed to be with the >alignments in the right place. > >Maybe, but builtin gdiplus has its own world transform and doesn't use >the gdi32 one. That's what transform_and_round_points is for. True but you're still using the GDI32 DrawText to actually render the text. transform_and_round_points is only doing what it says, transforming the coordinates. If you rotate the text by 90 degrees, DrawText is still going to have to be aware that the text is to be rotated 90 degrees to draw it correctly or else you'll get your text at the right position, but the text direction will be wrong. Unless I'm overlooking something? > >> Ok question then, how do I separate this into two patches? Never done >anything with patches like this before so this is a first for me. > >Just make two commits in Git, and format-patch will create two patch files. > That makes sense but, one question there. Does this mean I'm going to have to restore the file to it's original state, then add the one change, commit, add the other change, then commit again? With a change of this size, that isn't that big a deal. But on larger changes I could see that being a bit problematic. But maybe I'm just not used to it. =) Thanks, Stephan

3 3

Re: kernel32/tests: Add tests for GetLocaleInfo with SUBLANG_NEUTRAL
by Paul Vriens 02 Jun '09

02 Jun '09

Detlef Riekenberg wrote: > Add tests to show, that GetLocaleInfo assume SUBLANG_DEFAULT, > when called with an LCID that provide SUBLANG_NEUTRAL > > > > > ------------------------------------------------------------------------ > > Hi Detlef, This one introduces failures on NT4 and below and on some boxes with a non-English locale. Could you have a look? -- Cheers, Paul.

2 1

Re: gdiplus: add support for string alignment to GdipDrawString (try 2)
by Vincent Povirk 02 Jun '09

02 Jun '09

(reply didn't go to list as I expected, grr..) > Naw, it should still work normally. I've done aligned & rotated text under windows before with DrawTextW, you still pass the rect like you would if it wasn't rotated and set the alignment flags. The world transform should take care of getting it all rotated to where it is supposed to be with the alignments in the right place. Maybe, but builtin gdiplus has its own world transform and doesn't use the gdi32 one. That's what transform_and_round_points is for. > Ok question then, how do I separate this into two patches? Never done anything with patches like this before so this is a first for me. Just make two commits in Git, and format-patch will create two patch files.

1 0

Re: gdiplus: add support for string alignment to GdipDrawString (try 2)
by Stephan Rose 02 Jun '09

02 Jun '09

>Without doing any actual testing: > >The vertical alignment stuff looks right to me. > >Horizontal alignment is suspicious. If the world transform rotates the >text 90 degrees, DrawTextW can't be getting enough information to >center the text. Then again, I'm not sure if rotation works properly >with GdipDrawString in general. I'd write a test program for rotated >text. Naw, it should still work normally. I've done aligned & rotated text under windows before with DrawTextW, you still pass the rect like you would if it wasn't rotated and set the alignment flags. The world transform should take care of getting it all rotated to where it is supposed to be with the alignments in the right place. But I agree with you though, a test with rotated text is needed. If necessary though it isn't a big deal for me to change things to align without using DT_CENTER and DT_RIGHT. I'd want to test with the alignment flags first though as it keeps the code simpler if I can stick with those. > >I would probably send this as a series of 2 patches with vertical >alignment first. Ok question then, how do I separate this into two patches? Never done anything with patches like this before so this is a first for me. > >In spite Paul Vriens' comments, don't change the formatting of code >you're not changing. I guess the existing if's are already >inconsistent enough that you can get away with either style (and that >might actually be my fault). Without looking at it, I think it was only two if statements that weren't mine that I modified formatting on. Figured my changes to the function were major enough to where getting those two consistent with everything else wouldn't matter much. Up to you all if you want me to just leave those untouched or get their formatting in line with everything else. Either way's fine by me. =) Stephan

1 0

Re: gdiplus: add support for string alignment to GdipDrawString (try 2)
by Vincent Povirk 02 Jun '09

02 Jun '09

Without doing any actual testing: The vertical alignment stuff looks right to me. Horizontal alignment is suspicious. If the world transform rotates the text 90 degrees, DrawTextW can't be getting enough information to center the text. Then again, I'm not sure if rotation works properly with GdipDrawString in general. I'd write a test program for rotated text. I would probably send this as a series of 2 patches with vertical alignment first. In spite Paul Vriens' comments, don't change the formatting of code you're not changing. I guess the existing if's are already inconsistent enough that you can get away with either style (and that might actually be my fault). Vincent Povirk On Tue, Jun 2, 2009 at 7:12 AM, Stephan Rose<kermos(a)somrek.net> wrote: > - Adds support for aligning a string inside the given bounding rectangle > for GdipDrawString. Both vertical and horizontal alignments implemented. > > - Fixed code formatting issues (tabs / spaces, location of braces) to be > consistent with existing code. > > > > > >

1 0

Re: Website: Point the Development pages entirely to the Wiki.
by Jeremy Newman 02 Jun '09

02 Jun '09

I'm holding this patch hostage until the Wiki is updated with the new theme. -Newman Jeremy White wrote: > --- > templates/en/home.template | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/templates/en/home.template b/templates/en/home.template > index bad2f62..870a934 100644 > --- a/templates/en/home.template > +++ b/templates/en/home.template > @@ -24,8 +24,8 @@ > <div class="subtitle">Documentation, Support, and Wiki.</div> > </li> > > - <li class="devel" onClick="document.location='{$root}/devel/';"> > - <div class="title"><a href="{$root}/devel/">Development</a></div> > + <li class="devel" onClick="document.location='http://wiki.winehq.org/Developers';"> > + <div class="title"><a href="http://wiki.winehq.org/Developers">Development</a></div> > <div class="subtitle">Wine source, Bug Tracking, etc.</div> > </li> > > >

3 3

Re: Implications for Wine from the Ubuntu Developer Summit -- Pulseaudio
by Susan Cragin 02 Jun '09

02 Jun '09

>2009/6/2 Scott Ritchie <scott(a)open-vote.org>: >> First, I talked with a Pulseaudio expert about what we can do to make >> things work better. He said that if we want good compatibility we will >> need our ALSA stack to use the Pulseaudio safe subset: >> http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a >> metabug tracking this here: >> http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset >> can cause most problems with stuttering or even complete dropoff. > >As far as I know, this is not possible for Wine (without massive >latency issues caused by overbuffering in Wine itself) due to the fact >that Wine has to make DirectSound apps happy. It's also not very >consoling from this Pulseaudio expert that they don't seem to see a >problem with the ALSA layer on their end - "it's the apps that need to >be fixed". Wasn't the point of Pulse that you could use libasound/OSS >apps without modification? :) > >> I'm not completely familiar with how sound works in Wine, but in the >> past I remember that one complaint about PulseAudio over ALSA was >> latency. Latency issues these days are mostly due to bad kernel >> configurations > >PulseAudio will *always* have more latency than ALSA. This has nothing >to do with kernel configurations, just that using a >CONFIG_NO_HZ/CONFIG_HZ_1000 (or whatever it is) kernel from the -rt >tree makes the latency issue less severe. New kernel won't fix Wine + >Pulse problem. Forgive me in advance for interjecting dross into a technical discussion. Would part of the problem be solved if users could be given the option of installing pulseaudio? That way, some users would be made instantly happy. There is a subset of users (albeit a tiny subset) that just needs one sound application running, but wants that application running with crystal-clear sound and near-zero latency. These are certain professional audio users, and those who run Dragon NaturallySpeaking through wine. Those people may be ill-served by having pulseaudio at all. Right now, in wine, removing pulseaudio completely doesn't seem to return alsa's functionality. Wine/alsa freezes, and I have to use OSS emulation, but OSS just does not produce as high-quality a sound. PS -- The rt kernel really is wonderful for speech recognition or any other use. The repository version has problems that are being worked on. In the meantime, just compile your own.

1 0

Implications for Wine from the Ubuntu Developer Summit
by Scott Ritchie 02 Jun '09

02 Jun '09

Hello everyone, I've just returned from the Ubuntu Developer Summit in Barcelona last week. A lot of interesting stuff that concerns Wine happened there, and a lot of applies to every distro. I'll give a brief summary in this email. Audio: First, I talked with a Pulseaudio expert about what we can do to make things work better. He said that if we want good compatibility we will need our ALSA stack to use the Pulseaudio safe subset: http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a metabug tracking this here: http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset can cause most problems with stuttering or even complete dropoff. I'm not completely familiar with how sound works in Wine, but in the past I remember that one complaint about PulseAudio over ALSA was latency. Latency issues these days are mostly due to bad kernel configurations, which Lennart wrote about here: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150…. In the meantime we should develop for the future using kernels with preempt enabled at 1000 HZ. Currently neither Open SuSE nor Ubuntu are configured this way, however I know in the case of Ubuntu that this is being fixed for next release. In particular, if you develop on Ubuntu, you should either upgrade to Karmic Alphas or install a custom kernel. The -rt flavor of the kernel is known to have problems as well. Printing: A printing expert from http://openprinting.org says we should output .pdf files to cups rather than postscript. .pdf are becoming the standard for printers, and apparently they allow some good things that postscript does not. I've filed a bug on this here: http://bugs.winehq.org/show_bug.cgi?id=18741 Security and Usability: The security team thinks we should finally start respecting the execute bit - this means removing all MIME handlers for executable code from the desktop and replacing them with a single front end for programs lacking the execute bit. This front end would notify the user of the problem, scan the file for viruses, and then present some information about the path towards execution. It is still undecided whether the program should allow execution outright, however from a UI perspective this would clearly be more efficient. This creates a design challenge. In brief, we have to simultaneously manage expectations about Wine, inform the user that there are other (preferred) methods for installing software, not patronize them for installing a Windows program, tell them we scanned a file for viruses but that it may still be unsafe, make it easy to use, and make it hard to use accidentally. After input from the community and discussion with other designers, I believe I have some good ideas for how to handle these challenges. The Canonical design team has agreed to integrate the UI extensions I've gathered into their weekly user testing, so over the next few months we should be getting some real feedback on the merits of various approaches to this problem. I'll be working more on this personally, and already have a good chunk of the specifications and front end code done (thanks to some great community help). I will, of course, share it here when it's in a usable state. As far as we, as an upstream, are concerned, there's not much to change in Wine itself other than to keep making it work better and fix bugs. If I had to name one in particular, I'd have to say the "unclean removal of applications menu" entries is a particularly confusing issue for users. What I'm doing: Over the next few months I'm going to be working rather hard on the Karmic Wine Integration spec that I lead at the Summit: https://wiki.ubuntu.com/karmic-wine-integration. I'm still drafting the spec based on my notes and discussion, but at this point I have a very good idea of what I want to do. Most of the code involved is directly relevant to the Wine user, however almost none of it needs to go into Wine itself other than some icons. At this point it's mostly python scripts, modifications of other python programs, and Glade dialogs. I may set up a BZR/Git repository of the various bits once they start turning into actual packages (which I'll also be doing). Anyway, keep your eyes peeled, the next wave of distro releases are going to be very slick. Thanks, Scott Ritchie

5 6

Jump to page:

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 June 2009