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

Re: Severity levels

by Jerome Leclanche

Outside Major/Critical/Enhancement, I don't think severity useful, to be honest. Problem is, more often than not, a minor implementation glitch can result into an application breaking all around if it relies on it a lot. Which is pretty much the case with photoshop at the moment. Maybe it should be renamed to "impact", or something that would present itself differently to a first-time user. Or add a second severity field. I don't know, not my call. 2009/5/1 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > Hi all! > > First, I couldn't find any list more suitable than this one to comment the severity levels in the bug reporting so I post it here. If this was a really bad thing to do, please tell me were to do so. > Secondly, don't take this wrong, I am not here to preach, I actually think this is a serious problem. I am not drunk either. Currently. :-) > > So, with regards to severity levels: > > Current severity levels are perfect for server applications where everything is simply about functionality working or not working. > However, the overwhelming majority of windows applications in general, and those being ported through wine in particular are GUI-based, end-user applications. > When it comes to these kinds of applications, in front of which actual people sit for hours on end doing actual work, other factors come into play. > > So I would like to introduce a bold new weight into the severity assessment: The user experience. Or at least the bugs' negative impact on it. > The user experience(UE from here on) is really quite impossible to quantify exactly, luckily that is not usually necessary. > > There are several reasons to incorporate this into the severity classification, but I'll stop at two: > > 1. The ones reporting the bugs will come across with how severe they think the bug is to them. > Currently, there is far too much of "you've got a almost black screen or black square instead of icons running Photoshop?..hmm that's really trivial...an 'UI glitch', but OK then, I'll mark it minor to be nice to ya." > To a user, even an advanced one, this must feel like talking to a condescending Martian. Frustrating, if not infuriating. > Likely, they will never again take the time to make a bug report. It is even quite likely that they will give up their move away from windows. > > 2. Currently, fixing a "trivial" UE-bug can make way more users happy than fixing a "normal" functionality-bug. > This means that bug fixing is prioritized on a basis other than catering to the users needs. And to me, that's something that really shows. > Can one defend this without invalidating the wine project? > It is a serious question, I might have missed something fundamental. > > Anyway, I have some ideas on how to make the severity classifications better(and more intuitive for the mere user), but I won't go in to that now. > I just want to know if any of you agree with me. Do I make a valid point? > > //Nicklas > > PS. > I repost this since I didn't get any post from the server the first time. > Also I expect this post to piss some off, which makes it even stranger not to get any replies at all. > BTW, I also just read in a comment in a bug report that the severity flag doesn't mean much at all when it comes to how a bug is prioritized. > So the only input the users have on how important a bug is to them is practically ignored? Why have that checkbox then? > And why make such a big thing of it not being correctly set? > DS. > > > > -- Adys

May 2, 2009

Re: Wine fundraising idea

by Scott Ritchie

Austin English wrote: > Howdy, > > I was reading through a GSoC thread on how people are spending their > coding money. Someone posted that they thought people should donate to > miro, the internet HDTV player. They've got a pretty neat donation > scheme, where people can 'adopt' a line of code, and get updates on > it, etc. Pretty neat: > https://www.getmiro.com/adopt/ > > Just food for thought, for those of y'all wanting to add $ to the > WineHQ coffers, for WineConf, or what not (*cough* test/compile farm > *cough*). > This is functionally similar to asking for people to become members of some sort of foundation (eg monthly or annual contribution). It's a funding model that works, which is why they do it for public radio. I think there's real potential here. Thanks, Scott Ritchie

May 2, 2009

Re: msi/tests: Fix MsiApplyMultiplePatches tests on Windows.

by Juan Lang

Hi Nicolas, - ok(DeleteFileA("lithium.txt"), "Expected lithium.txt to exist\n"); + ok(DeleteFileA("lithium.txt"), "Expected lithium.txt to exist\n"); Please don't include whitespace-only changes in your patch. - + Same here. Thanks, --Juan

May 1, 2009

Re: user32: combine horizontal and vertical window scroll bar info in a single structure.

by Alexandre Julliard

Rein Klazes <wijn(a)online.nl> writes: > What is already in the tests: > > 1) You need the alloc flag for instance when SetScrollInfo or > SetScrollRange is called on a window without the WS_[HV]SCROLL styles. I > can add a test that shows that the window styles remain unchanged when > eg. SetScrollInfo creates the scrollinfo. > > 2) You need the style test when testing GetScrollInfo and GetScrollRange > on windows with WS_[HV]SCROLL styles. > > Now the alloc flag may not be specified correctly in the other cases > Additional tests to see whether the alloc flag is correctly passed for > [GS}etScrollBarInfo and EnableScrollBar can be added. > > Would such tests address your concerns? No, what you'd need is a test that shows that calling a function that doesn't create a scrollbar (alloc=FALSE) suddenly starts to create one if WS_[HV]SCROLL is set. To test this meaningfully you'd need to set the style by hand, not at window creation. -- Alexandre Julliard julliard(a)winehq.org

May 1, 2009

Re: FYI: 64-Bit Winelib-compilation

by André Hentschel

Austin English schrieb: > 2009/5/1 André Hentschel <nerv(a)dawncrow.de>: > >> To my suprise it didnt run. >> > > Interesting...does it run as a 32-bit winelib app? Have you tried > compiling it with 64-bit mingw and seeing if it works there? > > Putty runs as 32-bit winelib app. The test with mingw64 i will try next days.

May 1, 2009

Re: FYI: 64-Bit Winelib-compilation

by Austin English

2009/5/1 André Hentschel <nerv(a)dawncrow.de>: > To my suprise it didnt run. Interesting...does it run as a 32-bit winelib app? Have you tried compiling it with 64-bit mingw and seeing if it works there? -- -Austin

May 1, 2009

FYI: 64-Bit Winelib-compilation

by André Hentschel

Hi, these days i got my gcc 4.4 working and first compiled wine64. Next thing i did was to modify winemaker to generate Makefiles for 64-Bit compilation. I first tried something simple and it worked great, so i took my modified Putty-sourcecode and gave it a try. And wow it worked great! Just compiled fine. To my suprise it didnt run. Since todays git, the modified winemaker got in and i hope it might be usefull! Best regards André Hentschel

May 1, 2009

Severity levels

by Nicklas Börjesson

Hi all! First, I couldn't find any list more suitable than this one to comment the severity levels in the bug reporting so I post it here. If this was a really bad thing to do, please tell me were to do so. Secondly, don't take this wrong, I am not here to preach, I actually think this is a serious problem. I am not drunk either. Currently. :-) So, with regards to severity levels: Current severity levels are perfect for server applications where everything is simply about functionality working or not working. However, the overwhelming majority of windows applications in general, and those being ported through wine in particular are GUI-based, end-user applications. When it comes to these kinds of applications, in front of which actual people sit for hours on end doing actual work, other factors come into play. So I would like to introduce a bold new weight into the severity assessment: The user experience. Or at least the bugs' negative impact on it. The user experience(UE from here on) is really quite impossible to quantify exactly, luckily that is not usually necessary. There are several reasons to incorporate this into the severity classification, but I'll stop at two: 1. The ones reporting the bugs will come across with how severe they think the bug is to them. Currently, there is far too much of "you've got a almost black screen or black square instead of icons running Photoshop?..hmm that's really trivial...an 'UI glitch', but OK then, I'll mark it minor to be nice to ya." To a user, even an advanced one, this must feel like talking to a condescending Martian. Frustrating, if not infuriating. Likely, they will never again take the time to make a bug report. It is even quite likely that they will give up their move away from windows. 2. Currently, fixing a "trivial" UE-bug can make way more users happy than fixing a "normal" functionality-bug. This means that bug fixing is prioritized on a basis other than catering to the users needs. And to me, that's something that really shows. Can one defend this without invalidating the wine project? It is a serious question, I might have missed something fundamental. Anyway, I have some ideas on how to make the severity classifications better(and more intuitive for the mere user), but I won't go in to that now. I just want to know if any of you agree with me. Do I make a valid point? //Nicklas PS. I repost this since I didn't get any post from the server the first time. Also I expect this post to piss some off, which makes it even stranger not to get any replies at all. BTW, I also just read in a comment in a bug report that the severity flag doesn't mean much at all when it comes to how a bug is prioritized. So the only input the users have on how important a bug is to them is practically ignored? Why have that checkbox then? And why make such a big thing of it not being correctly set? DS.

May 1, 2009

Re: user32: combine horizontal and vertical window scroll bar info in a single structure.

by Rein Klazes

On Fri, 01 May 2009 13:13:05 +0200, you wrote: >Rein Klazes <wijn(a)online.nl> writes: > >> - if (!infoPtr && alloc) >> + if (!infoPtr && ( alloc || (wndPtr->dwStyle & (WS_VSCROLL | WS_HSCROLL)))) >> { > >This bit doesn't look right, and defeats the purpose of the alloc >flag. It would need some more test cases. The alloc flag is not only set by SCROLL_DrawScrollBar, which may be what you are thinking of here. What is already in the tests: 1) You need the alloc flag for instance when SetScrollInfo or SetScrollRange is called on a window without the WS_[HV]SCROLL styles. I can add a test that shows that the window styles remain unchanged when eg. SetScrollInfo creates the scrollinfo. 2) You need the style test when testing GetScrollInfo and GetScrollRange on windows with WS_[HV]SCROLL styles. Now the alloc flag may not be specified correctly in the other cases Additional tests to see whether the alloc flag is correctly passed for [GS}etScrollBarInfo and EnableScrollBar can be added. Would such tests address your concerns? Rein.

May 1, 2009

Re: Sound problems with latest kernel -- formerly a pulseaudio thread but not any more

by Michael Stefaniuc

Ben Klein wrote: > 2009/5/1 Susan Cragin <susancragin(a)earthlink.net>: >>> I filed ubuntu bug 369762. >> Ubuntu didn't think much of my bug. They sent me the following recipe to cure it, and marked the bug invalid. >> >> 1) Edit /etc/pulse/client.conf, and change "autospawn = yes" to "autospawn = no" >> 2) `touch $HOME/.pulse_a11y_nostart' >> 3) `asoundconf list' >> 4) choose the desired card from the previous command's output, and use `asoundconf set-default-card CARD', replacing CARD as appropriate >> 5) `killall pulseaudio' >> >> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/348353 >> mentions a recent kernel patch that routes all audio through pulse. I wonder if this patch is the culprit? > > It mentions a patch, not a kernel patch. I'd be *very* surprised if > there was anything kernel-side specifically routing audio through There is a kernel patch to reroute character devices to user space; afair that patch is already in. The usage example I have seen given for that patch is to reroute /dev/dsp to pulseaudio. > pulse. More plausibly, it could be a libasound2 patch or even just a > hack to asound.conf/.asoundrc. bye michael

May 1, 2009