April 2009 - Wine-Devel - list.winehq.org

Re: gdi32/enhmfdrv: Actaully save the state in SaveDC and RestoreDCin the metafile

by Aric Stewart

Hi Dmitry, Yeah, Alexandre did not like any of my patches and feels that duplicating the GDI code would be incorrect (it would result in too many SelectObject records and such) so he had me write up patch with a bunch of tests as wine_todos that demonstrate the problem so he could think about how to make it work. -aric Dmitry Timoshkov wrote: > It would be cleaner to check for GDI_NO_MORE_WORK in > SaveDC/RestoreDC instead of duplicating their code. >

April 4, 2009

Re: gdi32/enhmfdrv: Actaully save the state in SaveDC and RestoreDCin the metafile

by Dmitry Timoshkov

It would be cleaner to check for GDI_NO_MORE_WORK in SaveDC/RestoreDC instead of duplicating their code. -- Dmitry.

April 4, 2009

Re: winemenubuilder: disable debug output for .desktop files

by Vincent Povirk

On Fri, Apr 3, 2009 at 4:05 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > I'll work on a patch for the FIXME thing. Turns out this is not "fairly easy" but actually "incredibly difficult". We have a fallback case at http://source.winehq.org/source/include/wine/debug.h#L133 with a macro that returns a statement that ends in a function call, omitting the arguments and semicolon. This allows us to do FIXME_(channel)("message\n");. I can handle this in the other cases (where the macro result ends in a macro that takes arguments), but I can't see a way to create a static variable in a statement that ends in a function call that we only execute sometimes. Vincent Povirk

April 3, 2009

Re: winemenubuilder: disable debug output for .desktop files

by Austin English

You forgot to CC wine-devel in your original e-mail: On Fri, Apr 3, 2009 at 4:05 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > On Fri, Apr 3, 2009 at 3:43 PM, Austin English <austinenglish(a)gmail.com> wrote: >> However, that's a separate issue from disabling output for .desktop >> files. I don't see many (any?) use cases where having that output when >> launched from a gui is useful. > > I've been toying with the idea for some time of creating a program > that launches things in a gui-ish way and grabs a log from them, > eliminating a source of error in logs. I never actually got any work > done on it. This change would make my vapourware useless. That's not related to vanilla Wine, it's your own application. That's still only a single vaporware case. The majority of current use cases, however, are people that are launching applications from those shortcuts and don't capture that information. If they're debugging, the first thing we tell them is to run from a terminal to get that information. You could parse the .desktop file and remove that WINEDEBUG information. >> Why couldn't you simply use a second WINEDEBUG="fixme+all,err+all" to >> override the variable in the .desktop file? > > The command is "env WINEPREFIX="..." WINEDEBUG=-all ...". No matter > what I set WINEDEBUG to when I start that, wine will see a WINEDEBUG > value of -all. I forgot about the 'env' part, thanks for clarifying. -- -Austin

April 3, 2009

Re: winemenubuilder: disable debug output for .desktop files

by Vincent Povirk

On Fri, Apr 3, 2009 at 4:09 PM, Austin English <austinenglish(a)gmail.com> wrote: > Why couldn't you simply use a second WINEDEBUG="fixme+all,err+all" to > override the variable in the .desktop file? The command is "env WINEPREFIX="..." WINEDEBUG=-all ...". No matter what I set WINEDEBUG to when I start that, wine will see a WINEDEBUG value of -all. Vincent Povirk

April 3, 2009

Re: winemenubuilder: disable debug output for .desktop files

by Austin English

On Fri, Apr 3, 2009 at 3:38 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > On Fri, Apr 3, 2009 at 3:29 PM, Austin English <austinenglish(a)gmail.com> wrote: >> Several games experience this problem, but it's difficult to use the >> quiet fixme approach, since they have variable information. Converting >> the fixme's to trace's/warn's may be a viable option. > > What if we abandoned "print FIXME the first time, print nothing > subsequent times" in favor of "print FIXME the first time, print > WARN|TRACE subsequent times"? > > I've personally lost some useful information in a debug log because of > the "FIXME once" idiom. I was explicitly asking for the gdiplus > channel and expected to see all the calls. > > A FIXME_ONCE macro could be written fairly easily that does this > efficiently (i.e. without writing the same code twice). I think that would be very useful, and would love to see that. However, that's a separate issue from disabling output for .desktop files. I don't see many (any?) use cases where having that output when launched from a gui is useful. -- -Austin

April 3, 2009

Re: winemenubuilder: disable debug output for .desktop files

by Vincent Povirk

On Fri, Apr 3, 2009 at 3:29 PM, Austin English <austinenglish(a)gmail.com> wrote: > Several games experience this problem, but it's difficult to use the > quiet fixme approach, since they have variable information. Converting > the fixme's to trace's/warn's may be a viable option. What if we abandoned "print FIXME the first time, print nothing subsequent times" in favor of "print FIXME the first time, print WARN|TRACE subsequent times"? I've personally lost some useful information in a debug log because of the "FIXME once" idiom. I was explicitly asking for the gdiplus channel and expected to see all the calls. A FIXME_ONCE macro could be written fairly easily that does this efficiently (i.e. without writing the same code twice). Vincent Povirk

April 3, 2009

Re: winemenubuilder: disable debug output for .desktop files

by Austin English

On Fri, Apr 3, 2009 at 3:19 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: > I'm not sure if this is a good idea. > > I don't think it's safe to assume that stderr will be lost if the > program was started from a .desktop file. The majority of users are double clicking .desktop files to start their applications. Where do you see stderr going to in this case? > If default debug output slows anything down noticeably, that should > probably be fixed. Several games experience this problem, but it's difficult to use the quiet fixme approach, since they have variable information. Converting the fixme's to trace's/warn's may be a viable option. -- -Austin

April 3, 2009

Re: winemenubuilder: disable debug output for .desktop files

by Vincent Povirk

I'm not sure if this is a good idea. I don't think it's safe to assume that stderr will be lost if the program was started from a .desktop file. If default debug output slows anything down noticeably, that should probably be fixed. Vincent Povirk On Fri, Apr 3, 2009 at 2:40 PM, Austin English <austinenglish(a)gmail.com> wrote: > Users aren't running in a terminal, so debug output only slows things down. > > -- > -Austin > > > >

April 3, 2009

Re: Windows 7

by Henri Verbeet

2009/4/3 Austin English <austinenglish(a)gmail.com>: > On Fri, Apr 3, 2009 at 3:06 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> 2009/4/3 Austin English <austinenglish(a)gmail.com>: >>> I'm not sure what the dwbuildnumber should be, I can't find that >>> information anywhere...Anywho, this should work. >>> >> RC1 was 0x1b9c, I think. > > Where do you get that information from? > The screenshot in the wikipedia article :-) (http://upload.wikimedia.org/wikipedia/en/b/bd/Windows_7.png) Although if someone had an actual copy you could just call GetVersionEx().

April 3, 2009