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

Re: winedbg and exceptions

by Eric Pouech

Christopher Harvey a écrit : > Hi, > I'm having trouble with winedbg and seh exceptions. I've got a program > that throws TONS of unhanded exceptions that don't seem to affect > behavior at all, but there is one exception that I'm after, it's an > access violation exception that's crashing a program. I can "run" the > program by holding enter in winedbg and telling it to cont on all > exceptions, but I've never managed to read the exception I want this > way. Basically I just need a backtrace from the violation. > > Chris. > > > > > unfortunately (compared to gcc behavior) we cannot (yet) in winedbg decide to filter out some exceptions and some other ones however, this may work: try the following commands (before run) set $BreakOnFirstChance=0 run and see what gives A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 5, 2009

winedbg and exceptions

by Christopher Harvey

Hi, I'm having trouble with winedbg and seh exceptions. I've got a program that throws TONS of unhanded exceptions that don't seem to affect behavior at all, but there is one exception that I'm after, it's an access violation exception that's crashing a program. I can "run" the program by holding enter in winedbg and telling it to cont on all exceptions, but I've never managed to read the exception I want this way. Basically I just need a backtrace from the violation. Chris.

May 5, 2009

Re: Severity levels

by Rosanne DiMesio

On Tue, 5 May 2009 13:28:45 -0400 (EDT) James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > The proposed impact field should be a drop down list only and present common > impacts encountered by users, such as "Unable to Install Application", > "Unable to run application","Screen is unreadable","Text not appearing on > screen","Graphics are garbled". If I can't install or run an app because text is not appearing on the screen and the graphics are garbled--in other words, the screen is unreadable--which item am I supposed to select? Or at the other extreme--what if my problem doesn't seem to match anything on the predefined list? >This allows the user to provide input > and allow the triage team to provide feedback to the user as well as > assign appropriate severity and priorities to bug reports. > There's already a field that does exactly that: the description. It allows users to describe the problem in as much detail as they wish, including its impact, and unlike a drop-down list, is not limited to common issues. I don't see what an additional field to repeat this information in vague terms will do to help anyone. -- Rosanne DiMesio <dimesio(a)earthlink.net>

May 5, 2009

Re: Severity levels

by James Mckenzie

Darragh Bailey wrote on May 5th: > >On Mon, May 04, 2009 at 11:24:58AM -0700, James Mckenzie wrote: >> Ben Klein wrote on May 4th: >> > >> >Final post from me. >> > >> >2009/5/5 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >> >> b) I thought that priority was developer priority and severity was >> >> severity for the users. >> > >> >Nope. Both for the benefit of developers, hence why they're both on bugzilla. >> > >> > >> One question: Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program? This is much different than the priority and severity fields. >> >> James McKenzie > >In catching up on this long discussion, this is the first post that I've >seen that actually comes close to pin-pointing what is being requested. > >Current: >Severity = messure of bug impact on wine > >Requested: >Severity = message of bug impact on application running in wine > > >IMHO the bugzilla severity field is not the right place to measure >impact to other applications of bugs in the current development. >Attempting to track that type of information in the severity field >will always lead to confusion and problems. > As a reminder, Bugzilla is for developers to work in user discovered issues. The Severity field, as it is, is correct for developer/triage evaluation of discovered issues. It should not be changed. However, a developer should be aware of the impact on the user experience and the user's determined severity of a problem. Users should not be determining this through the use of the severity and priority fields. I have discussed the use of an impact field to have the user state what impact the problem has on their ability to use/install a particular application. Some problems have a more severe impact on certain applications. The use of metabugs to follow what applications are affected is HIGHLY discouraged. The users of Wine should be able to state, in one place, what the bug is, what its impact to them is and the status of repair and/or workaround(s) for the bug is. The Applications Database is the location where a user can input what they found through use of Wine by Linux/UNIX version/distribution and Wine version. Bug reports should reside in Bugzilla and users should be able to input bug reports quickly (<10 minutes for a non-English speaking user.) This seems to not be happening at the present time and users are confused by the Bugzilla interface and fields presented to them. We should not rely on the ability for users to read and understand what field does what but only present to them fields needed to be filled out by users when they submit a bug report. Since the severity and priority fields are developer only, they should not be present. The proposed impact field should be a drop down list only and present common impacts encountered by users, such as "Unable to Install Application", "Unable to run application","Screen is unreadable","Text not appearing on screen","Graphics are garbled". This allows the user to provide input and allow the triage team to provide feedback to the user as well as assign appropriate severity and priorities to bug reports. Please advise if this is what the project desires to do. Again, this is to improve the user experience for the unexperienced (nOOb) Wine user. Experienced users do not have these difficulties but this takes time away from developers and triage teams to provide user education. James McKenzie

May 5, 2009

Re: Severity levels

by Austin English

On Tue, May 5, 2009 at 9:42 AM, Darragh Bailey <felix(a)compsoc.nuigalway.ie> wrote: > In catching up on this long discussion, this is the first post that I've > seen that actually comes close to pin-pointing what is being requested. > > Current: > Severity = messure of bug impact on wine > > Requested: > Severity = message of bug impact on application running in wine > > > IMHO the bugzilla severity field is not the right place to measure > impact to other applications of bugs in the current development. > Attempting to track that type of information in the severity field > will always lead to confusion and problems. > > A more logical approach would be to either add a different field or use > tags to track the impact on the affected app. Again, bugzilla is a developer's tool. That sort of information belongs in the AppDB, not bugzilla. -- -Austin

May 5, 2009

Re: comdlg: implemented notifications are only sent with OFN_EXPLORER flag set

by Austin English

On Tue, May 5, 2009 at 5:42 AM, Ricardo Filipe <ricardojdfilipe(a)gmail.com> wrote: > as MSDN says and some manual testing i did shows these CDN notifications are > only sent if OFN_EXPLORER is sent in the dialog flags. You forgot the patch. -- -Austin

May 5, 2009

Re: can't find winedbg

by Ken Sharp

Vitaliy Margolen wrote: > Ben Klein wrote: >> 2009/5/5 Vitaliy Margolen <wine-devel(a)kievinfo.com>: >>> Mike Kaplinskiy wrote: >>>> executable, so you would run it like: >>>> >>>> ./wine ./programs/winedbg/winedbg.exe.so >>> './wine winedbg' will do the same. >> Will that look-up in ./programs/winedbg before looking in $PREFIX/lib/wine/? > Should. I don't have Wine installed (and never had) but winedbg, notepad, > winecfg & all other programs work just fine. > It seems to. ./wine is a wrapper, you should be able to open it in a text editor and have a look.

May 5, 2009

Re: can't find winedbg

by Vitaliy Margolen

Ben Klein wrote: > 2009/5/5 Vitaliy Margolen <wine-devel(a)kievinfo.com>: >> Mike Kaplinskiy wrote: >>> executable, so you would run it like: >>> >>> ./wine ./programs/winedbg/winedbg.exe.so >> './wine winedbg' will do the same. > > Will that look-up in ./programs/winedbg before looking in $PREFIX/lib/wine/? Should. I don't have Wine installed (and never had) but winedbg, notepad, winecfg & all other programs work just fine. Vitaliy.

May 5, 2009

Re: Severity levels

by Darragh Bailey

On Mon, May 04, 2009 at 11:24:58AM -0700, James Mckenzie wrote: > Ben Klein wrote on May 4th: > > > >Final post from me. > > > >2009/5/5 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > >> b) I thought that priority was developer priority and severity was > >> severity for the users. > > > >Nope. Both for the benefit of developers, hence why they're both on bugzilla. > > > > > One question: Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program? This is much different than the priority and severity fields. > > James McKenzie In catching up on this long discussion, this is the first post that I've seen that actually comes close to pin-pointing what is being requested. Current: Severity = messure of bug impact on wine Requested: Severity = message of bug impact on application running in wine IMHO the bugzilla severity field is not the right place to measure impact to other applications of bugs in the current development. Attempting to track that type of information in the severity field will always lead to confusion and problems. A more logical approach would be to either add a different field or use tags to track the impact on the affected app. -- Darragh "Nothing is foolproof to a sufficiently talented fool."

May 5, 2009

Re: Severity levels

by Paul TBBle Hampson

On Mon, May 04, 2009 at 02:39:28PM -0500, Austin English wrote: > 2009/5/4 James Mckenzie <jjmckenzie51(a)earthlink.net>: >> One question: Does Bugzilla have a place for user's to place the >> Impact on their ability to use a Windows program? This is much >> different than the priority and severity fields. > No, but it is not important for bugzilla. That information belongs in > the AppDB, which allows for this, with the application ratings. It'd be handy if bug links in AppDB allowed some kind of indication of the problem it causes or at least the severity thereof. I've got a whole bunch of bugs linked from Warhammer Online which have really unuseful bug titles, causing readers of the page to end up reporting the same things in the comments. There's prolly an issue as well in the bug report naming, it seems that Wine doesn't have a strong culture of renaming bugs when they've been diagnosed. (Bug 13335 is a good example of this, I feel. A user pointed out to me the other day that he wasn't running Warcraft 3 when I suggested that it was the problem he was having. There's another bug which refers specifically to Steam in the bug title.) I've added a Note to the WAR AppDB page which describes symptoms and ties them to linked bugs to try and alleviate this, but it'd be nice if the disconnect wasn't there. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

May 5, 2009

Re: user32: fix a signed/unsigned issue in MENU_PopupMenuCalcSize

by Alexandre Julliard

Rein Klazes <wijn(a)online.nl> writes: > fix for bug #18354 That's only hiding the bug, the height shouldn't become negative. -- Alexandre Julliard julliard(a)winehq.org

May 5, 2009

Re: [PATCH 1/2] [User32]: clearly separe the 16bit code out of user32

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > @@ -145,14 +146,101 @@ HDDEDATA WDML_InvokeCallback16(PFNCALLBACK pfn, UINT uType, UINT uFmt, > return ret; > } > > +#define MAX_THUNKS 32 > +/* As DDEML doesn't provide a way to get back to an InstanceID when > + * a callback is run, we use thunk in order to implement simply the > + * 32bit->16bit callback mechanism. > + * For each 16bit instance, we create a thunk, which will be passed as > + * a 32bit callback. This thunk also stores (in the code!) the 16bit > + * address of the 16bit callback, and passes it back to > + * WDML_InvokeCallback16. > + * The code below is mainly to create the thunks themselved > + */ > +static struct ddeml_thunk > +{ > + DWORD instId; /* instance ID */ > + SEGPTR pfn16; /* 16bit callback address */ > + /* start: ; 32bit callback */ > + BYTE call; /* call get_eip */ > + DWORD call_rel32; /* */ > + /* get_eip: */ > + BYTE pop_eax; /* pop %eax ; eip of get_eip */ > + BYTE pop_ecx; /* pop %ecx ; return address */ > + BYTE push_pfn[3];/* pushl -0x9(%eax) ; push pfn16 */ > + BYTE push_ecx; /* pushl %ecx */ > + BYTE push; /* push $DDEML_InstanceCallback16 */ > + DWORD cb16; /* */ > + BYTE ret; /* ret ; jmp DDEML_InstanceCal...*/ > +} *DDEML16_Thunks; It doesn't really make sense to build position-independent code for a thunk that is at a known address. Plus you don't even need the address, a simple pushl $pfn16 would work just as well. Look at how winproc thunks are done. -- Alexandre Julliard julliard(a)winehq.org

May 5, 2009

GUI debugging

by Benoit SCHWINDEN

Reece Dunn a écrit : > 2009/5/5 Austin English <austinenglish(a)gmail.com>: > >> On Tue, May 5, 2009 at 2:13 AM, Benoit SCHWINDEN >> <benoit.schwinden(a)unistra.fr> wrote: >> >>> Hello, >>> >>> I am trying to make a very special application working with Wine 1.1.20 >>> (Loris, from Ever Ezida, a library management software). Almost >>> everything is functionnal, but there is a little graphical bug with some >>> texfields. Also, I would like to know if there are some ways to debug a >>> GUI, especially a way to know which library or DLL is called to display >>> a part of this GUI (ie know what DLL is used to display my faulties text >>> fields). >>> >> If any terminal output is triggered by activating/interacting with >> that area, it'd be a good place to look. >> >> Otherwise, +relay would tell you, but it'll also give you a lot more >> information that you don't need. >> > > Most of the UI is located in user32 and comctl32. Is it a plain text > filed (could be the edit control in user32), or a formatted edit field > (could be the richedit control in riched32), or it could be a custom > written control in Loris itself. > > I would suggest that you file a bug and attach a screenshot. > OK it's done ! > Some general pointers: > 1. it could be to do with theming (if you have installed and are > using a Windows theme such as Zune); > no theme installed... > 2. it could be due to using an incorrect font or locale that has > missing characters for things like "e with acute"; > 3. the program could be expecting Windows fonts and font > characteristics (have you tried installing MS core fonts using > winetricks: http://wiki.winehq.org/winetricks?) > 4. it could be an issue with font smoothing. > > - Reece > It is not a font problem, the text displayed in the faulty field is fine, but the field is too small, that is the problem. Screenshot in bug report 18362. Thanks a lot for your help ! -- Benoit SCHWINDEN Direction Informatique Groupe GNU/Linux Université de Strasbourg 03 90 24 12 46

May 5, 2009

Re: winmm: Added Polish translation

by Alexandre Julliard

Łukasz Wojniłowicz <lukasz.wojnilowicz(a)gmail.com> writes: > dlls/winmm/winmm_Pl.rc | 126 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 126 insertions(+), 0 deletions(-) > create mode 100644 dlls/winmm/winmm_Pl.rc Adding the file won't have any effect unless you include it from the main resource file. -- Alexandre Julliard julliard(a)winehq.org

May 5, 2009

Re: GUI debugging

by Reece Dunn

2009/5/5 Austin English <austinenglish(a)gmail.com>: > On Tue, May 5, 2009 at 2:13 AM, Benoit SCHWINDEN > <benoit.schwinden(a)unistra.fr> wrote: >> Hello, >> >> I am trying to make a very special application working with Wine 1.1.20 >> (Loris, from Ever Ezida, a library management software). Almost >> everything is functionnal, but there is a little graphical bug with some >> texfields. Also, I would like to know if there are some ways to debug a >> GUI, especially a way to know which library or DLL is called to display >> a part of this GUI (ie know what DLL is used to display my faulties text >> fields). > > If any terminal output is triggered by activating/interacting with > that area, it'd be a good place to look. > > Otherwise, +relay would tell you, but it'll also give you a lot more > information that you don't need. Most of the UI is located in user32 and comctl32. Is it a plain text filed (could be the edit control in user32), or a formatted edit field (could be the richedit control in riched32), or it could be a custom written control in Loris itself. I would suggest that you file a bug and attach a screenshot. Some general pointers: 1. it could be to do with theming (if you have installed and are using a Windows theme such as Zune); 2. it could be due to using an incorrect font or locale that has missing characters for things like "e with acute"; 3. the program could be expecting Windows fonts and font characteristics (have you tried installing MS core fonts using winetricks: http://wiki.winehq.org/winetricks?) 4. it could be an issue with font smoothing. - Reece

May 5, 2009

Re: GUI debugging

by Benoit SCHWINDEN

Austin English a écrit : > On Tue, May 5, 2009 at 2:13 AM, Benoit SCHWINDEN > <benoit.schwinden(a)unistra.fr> wrote: > >> Hello, >> >> I am trying to make a very special application working with Wine 1.1.20 >> (Loris, from Ever Ezida, a library management software). Almost >> everything is functionnal, but there is a little graphical bug with some >> texfields. Also, I would like to know if there are some ways to debug a >> GUI, especially a way to know which library or DLL is called to display >> a part of this GUI (ie know what DLL is used to display my faulties text >> fields). >> > > If any terminal output is triggered by activating/interacting with > that area, it'd be a good place to look. > > Otherwise, +relay would tell you, but it'll also give you a lot more > information that you don't need. > > Thank you ! Yes +relay sends a lot of things. It appears that my faulty dll is user32.dll (very surprising, isn't it ? :-) ) Unfortunately no terminal output is sent during Loris execution. The text area appears, but it is too small. -- Benoit SCHWINDEN Direction Informatique Groupe GNU/Linux Université de Strasbourg 03 90 24 12 46

May 5, 2009

Re: GUI debugging

by Austin English

On Tue, May 5, 2009 at 2:13 AM, Benoit SCHWINDEN <benoit.schwinden(a)unistra.fr> wrote: > Hello, > > I am trying to make a very special application working with Wine 1.1.20 > (Loris, from Ever Ezida, a library management software). Almost > everything is functionnal, but there is a little graphical bug with some > texfields. Also, I would like to know if there are some ways to debug a > GUI, especially a way to know which library or DLL is called to display > a part of this GUI (ie know what DLL is used to display my faulties text > fields). If any terminal output is triggered by activating/interacting with that area, it'd be a good place to look. Otherwise, +relay would tell you, but it'll also give you a lot more information that you don't need. -- -Austin

May 5, 2009

GUI debugging

by Benoit SCHWINDEN

Hello, I am trying to make a very special application working with Wine 1.1.20 (Loris, from Ever Ezida, a library management software). Almost everything is functionnal, but there is a little graphical bug with some texfields. Also, I would like to know if there are some ways to debug a GUI, especially a way to know which library or DLL is called to display a part of this GUI (ie know what DLL is used to display my faulties text fields). Thanks a lot by advance. Best regards, Benoit. -- Benoit SCHWINDEN Direction Informatique Groupe GNU/Linux Université de Strasbourg 03 90 24 12 46

May 5, 2009

Re: can't find winedbg

by Ben Klein

2009/5/5 Vitaliy Margolen <wine-devel(a)kievinfo.com>: > Mike Kaplinskiy wrote: >> executable, so you would run it like: >> >> ./wine ./programs/winedbg/winedbg.exe.so > > './wine winedbg' will do the same. Will that look-up in ./programs/winedbg before looking in $PREFIX/lib/wine/?

May 5, 2009

Re: can't find winedbg

by Vitaliy Margolen

Mike Kaplinskiy wrote: > executable, so you would run it like: > > ./wine ./programs/winedbg/winedbg.exe.so './wine winedbg' will do the same. Vitaliy.

May 5, 2009

Re: Severity levels

by John Klehm

Roderick Colenbrander and I were talking about the severity levels on irc the other day. We tried to outline the existing severity process that seems to be in use (not what is neccesarily listed in bugzilla) and came up with the following levels of bug severity: * normal * major (release level, e.g. dib engine, 64 bit support, usb, etc) * blocker (compile failure, severe wine crash, system crash due to triggering driver bugs) As far as I can see that's what the current usage of serverity is in bugzilla. Other thoughts during our discussion were that perhaps assignee should be the one that can change the severity rather than reporter. Cheers, --John Klehm

May 5, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Juan Lang

> How about? > > ERR("didn't find any trusted root certificates. Are they installed?\n"); Done, and sent. Thanks for the suggestion and the help. --Juan

May 5, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Austin English

On Mon, May 4, 2009 at 8:51 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> I'm a bit busy with other things, so time's a bit short. Would you >> mind pointing me in the right direction for the best approach for >> this? Or perhaps send a patch? <g> > > Sure. How's the attached look to you? Should it be an ERR instead? That was quick, thanks! Yes, please make it an error. It shoudn't happen very often, and it can be pretty fatal, for, e.g., iTunes. > What text would you find more helpful? How about? ERR("didn't find any trusted root certificates. Are they installed?\n"); -- -Austin

May 5, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Juan Lang

> I'm a bit busy with other things, so time's a bit short. Would you > mind pointing me in the right direction for the best approach for > this? Or perhaps send a patch? <g> Sure. How's the attached look to you? Should it be an ERR instead? What text would you find more helpful? --Juan

May 5, 2009

Re: can't find winedbg

by Christopher Harvey

Ben Klein wrote: > 2009/5/5 Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com>: > >> On Mon, May 4, 2009 at 9:27 PM, Christopher Harvey >> <chris(a)basementcode.com> wrote: >> >>> I just built wine out of git. >>> Ran this: >>> wine-git $ find . -name winedbg >>> ./programs/winedbg >>> >>> notice there is no winedbg program. The output there is a folder only. >>> Where is the winedbg program within the git tree? >>> >>> >> I'm pretty sure it's inside that folder and it itself is a wine >> executable, so you would run it like: >> >> ./wine ./programs/winedbg/winedbg.exe.so >> > > Indeed. This will yield the results you want: > $ find . -type f -name 'winedbg*' > > Got it going. thanks. I did a bit of wine dev a few years back. I don't remember it being like this. Maybe this should be noted on the developers cheat sheet and manual, if it isn't already.

May 5, 2009

Re: can't find winedbg

by Ben Klein

2009/5/5 Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com>: > On Mon, May 4, 2009 at 9:27 PM, Christopher Harvey > <chris(a)basementcode.com> wrote: >> I just built wine out of git. >> Ran this: >> wine-git $ find . -name winedbg >> ./programs/winedbg >> >> notice there is no winedbg program. The output there is a folder only. >> Where is the winedbg program within the git tree? >> > I'm pretty sure it's inside that folder and it itself is a wine > executable, so you would run it like: > > ./wine ./programs/winedbg/winedbg.exe.so Indeed. This will yield the results you want: $ find . -type f -name 'winedbg*'

May 5, 2009

Re: can't find winedbg

by Mike Kaplinskiy

On Mon, May 4, 2009 at 9:27 PM, Christopher Harvey <chris(a)basementcode.com> wrote: > I just built wine out of git. > Ran this: > wine-git $ find . -name winedbg > ./programs/winedbg > > > notice there is no winedbg program. The output there is a folder only. > Where is the winedbg program within the git tree? > > > I'm pretty sure it's inside that folder and it itself is a wine executable, so you would run it like: ./wine ./programs/winedbg/winedbg.exe.so Mike.

May 5, 2009

can't find winedbg

by Christopher Harvey

I just built wine out of git. Ran this: wine-git $ find . -name winedbg ./programs/winedbg notice there is no winedbg program. The output there is a folder only. Where is the winedbg program within the git tree?

May 5, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Austin English

On Mon, May 4, 2009 at 4:57 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> Alternatively, how about printing an error in crypt32 itself if no >> trusted root certificates are found? That way applications get the >> same benefit, not just the test suite? E.g., how we do for ntlm_auth >> in secur32? > > That sounds like a good approach. > --Juan > I'm a bit busy with other things, so time's a bit short. Would you mind pointing me in the right direction for the best approach for this? Or perhaps send a patch? <g> -- -Austin

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Juan Lang

> Alternatively, how about printing an error in crypt32 itself if no > trusted root certificates are found? That way applications get the > same benefit, not just the test suite? E.g., how we do for ntlm_auth > in secur32? That sounds like a good approach. --Juan

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Austin English

On Mon, May 4, 2009 at 2:43 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Mon, May 4, 2009 at 12:19 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >>> We have a similar warning already: >>> http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ws2_32/tests/sock.c#l2… >> >> That warning is appropriate, because it's testing IPv6, so the warning >> applies in all cases. The reason I'm objecting in this case is that >> the warning is printed for any failure, no matter which chain is being >> checked, yet this condition can only occur on one of the 15 or so >> chains that are checked. Like I said, I think it's a special case. > > How about an if ( got->dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT ) ? > > -- > -Austin > Alternatively, how about printing an error in crypt32 itself if no trusted root certificates are found? That way applications get the same benefit, not just the test suite? E.g., how we do for ntlm_auth in secur32? -- -Austin

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Austin English

On Mon, May 4, 2009 at 12:19 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> We have a similar warning already: >> http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ws2_32/tests/sock.c#l2… > > That warning is appropriate, because it's testing IPv6, so the warning > applies in all cases. The reason I'm objecting in this case is that > the warning is printed for any failure, no matter which chain is being > checked, yet this condition can only occur on one of the 15 or so > chains that are checked. Like I said, I think it's a special case. How about an if ( got->dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT ) ? -- -Austin

May 4, 2009

Re: Added Polish translation

by Jeremy Newman

I tried applying this patch, but the files are corrupt. It looks like the UTF-8 encoding was not preserved. You should send the patch as an attachment instead of inline. -Newman Łukasz Wojniłowicz wrote: > --- > include/data.php | 4 + > templates/pl/.cvsignore | 2 + > templates/pl/announce.template | 7 ++ > templates/pl/download.template | 187 ++++++++++++++++++++++++++++++++++++ > templates/pl/download/deb.template | 102 ++++++++++++++++++++ > templates/pl/home.template | 90 +++++++++++++++++ > templates/pl/interview.template | 8 ++ > templates/pl/irc.template | 18 ++++ > templates/pl/lang.template | 37 +++++++ > templates/pl/news.template | 11 ++ > templates/pl/search.template | 26 +++++ > 11 files changed, 492 insertions(+), 0 deletions(-) > create mode 100644 templates/pl/.cvsignore > create mode 100644 templates/pl/announce.template > create mode 100644 templates/pl/download.template > create mode 100644 templates/pl/download/deb.template > create mode 100644 templates/pl/home.template > create mode 100644 templates/pl/interview.template > create mode 100644 templates/pl/irc.template > create mode 100644 templates/pl/lang.template > create mode 100644 templates/pl/news.template > create mode 100644 templates/pl/search.template > > diff --git a/include/data.php b/include/data.php > index a0e2f5f..c9a656b 100644 > --- a/include/data.php > +++ b/include/data.php > @@ -61,6 +61,10 @@ class data > 'name' => 'FranÃ§ais', > 'change' => 'Changez la langue' > ), > + 'pl' => array( > + 'name' => 'Polski', > + 'change' => 'ZmieÅ„ jÄ™zyk' > + ), > 'pt' => array( > 'name' => 'PortuguÃªs', > 'change' => 'Mudar a lÃngua' > diff --git a/templates/pl/.cvsignore b/templates/pl/.cvsignore > new file mode 100644 > index 0000000..0ba44f6 > --- /dev/null > +++ b/templates/pl/.cvsignore > @@ -0,0 +1,2 @@ > +docs > +winapi_stats.template > diff --git a/templates/pl/announce.template b/templates/pl/announce.template > new file mode 100644 > index 0000000..e8e15c0 > --- /dev/null > +++ b/templates/pl/announce.template > @@ -0,0 +1,7 @@ > + > + > + > +<h1 class="title">OgÅ‚oszenie nowego Wine</h1> > + > + > + > diff --git a/templates/pl/download.template b/templates/pl/download.template > new file mode 100644 > index 0000000..185dafa > --- /dev/null > +++ b/templates/pl/download.template > @@ -0,0 +1,187 @@ > + > + > + > +<h1 class="title">Pobieralnia Wine</h1> > + > +<h2 style="margin-bottom: 10px;"><a name="crossover"></a>Wine ze wsparciem technicznym</h2> > + > +<table border="0" cellpadding="5" cellspacing="1" bgcolor="#EFEFEF"> > + > + <tr> > + <td align="center" bgcolor="black"><b><font color="white" class="small">Produkt</font></b></td> > + <td align="center" bgcolor="black"><b><font color="white" class="small">Opis</font></b></td> > + </tr> > + > + <tr> > + <td align="center" bgcolor="#ffffff"> > + <a href="http://www.codeweavers.com/products/download_trial/"> > + <img src="{$root}/images/distro/crossover.png" > + width="50" height="50" alt="CrossOver Linux or Mac" border="0"> > + </a> > + </td> > + <td align="left" bgcolor="#ffffff"> > + <b><a href="http://www.codeweavers.com/products/">CrossOver</a></b> > + jest dobrze wykoñczon± wersj± dostarczan± przez <b><a href="http://www.codeweavers.com">CodeWeavers</a></b>. > + CrossOver usprawnia u¿ywanie Wine, a CodeWeavers zapewnia wspania³e wsparcie techniczne swoim u¿ytkownikom. Wszystkie fundusze ze sprzeda¿y CrossOvera s± przekazywane bezpo¶rednio jako wsparcie dla programistów pracuj±cych nad Wine. Tak wiêc CrossOver jest jest wspania³± drog± uzyskania wsparcia jak równie¿ wspierania Projektu Wine. CodeWeavers dostarcza w pe³ni funkcjonaln± <b><a href="http://www.codeweavers.com/products/download_trial/">wersjê trialow± CrossOver</a></b>. > + </td> > + </tr> > +</table> > + > +<p class="small" align="center">To poparcie jest g³ównym dowodem uznania wymaganym przez CodeWeavers w zamian za hostowanie strony Wine.</p> > + > + > +<h2 style="margin-bottom: 5px;"><a name="binary"></a>Pobieralnia binariów Wine</h2> > + > +<table style="margin: 0 0 15px 0;" width="100%"> > +<tr> > + <td width="200">Najnowsze stabilne wydanie:</td><td>Wine {$config_stable_release}</td> > + <td rowspan="2" valign="top" style="padding-left: 20px; text-align: center;"><b>Zajrzyj do > + <a href="http://wiki.winehq.org/HowTo">samouczka konfiguracji i instalacji</a> > + , aby zaznajomiæ siê z czynno¶ciami po-instalacyjnymi.</b></td> > +</tr> > +<tr> > + <td>Najnowsze rozwojowe wydanie:</td><td>Wine {$config_master_release}</td> > +</tr> > +</table> > + > +<table border="0" cellpadding="5" cellspacing="1" bgcolor="#EFEFEF"> > + > + <tr> > + <td align="center" bgcolor="black"><b><font color="white" class="small">System</font></b></td> > + <td align="center" bgcolor="black"><b><font color="white" class="small">Notki</font></b></td> > + <td align="center" bgcolor="black"><b><font color="white" class="small">Opiekun</font></b></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td align="center"><a href="{$root}/download/deb"> > + <img src="{$root}/images/distro/ubuntu.png" width="50" height="50" alt="Ubuntu linux" border="0"></a> > + </td> > + <td> <b><a href="{$root}/download/deb">Ubuntu</a></b> > + binare i ¼ród³owe paczki .deb dla Ubuntu Hardy (8.04), Intrepid (8.10), i Jaunty (9.04) > + <td><a href="mailto:scott(a)open-vote.org">Scott Ritchie</a></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td align=center><a href="{$root}/download/deblenny"> > + <img src="{$root}/images/distro/debian.png" width="50" height="50" alt="Debian Linux" border="0"></a> > + </td> > + <td> <b><a href="{$root}/download/deblenny">Debian</a></b> > + binarne paczki .deb dla Debian Lenny, Squeeze i Sid</td> > + <td><a href="mailto:repository(a)lamaresh.net">Maurilio Genovese</a><br><a href="mailto:ben.klein(a)lamaresh.net">Ben Klein</a></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td align="center"><a href="http://fedoraproject.org/wiki/AndreasBierfert/Wine"> > + <img src="{$root}/images/distro/redhat.png" width="50" height="50" alt="RedHat Linux" border="0"></a> > + </td> > + <td> <b><a href="http://fedoraproject.org/wiki/AndreasBierfert/Wine">Red Hat / CentOS / Fedora</a></b> > + binarne i ¼ród³owe .rpmy dla Red Hat Enterprise Linux 4, 5; CentOS 4, 5; Fedora Core 5, 6; Fedora Linux 7 i kompatybilnych dystrybucji > + The wine meta package is available via <tt>yum</tt> > + through the EPEL / Fedora Extras / Fedora repository by running <tt>$ yum install > + wine </tt>" > + </td> > + <td><a href="mailto:andreas.bierfert_at_lowlatency.de">Andreas Bierfert</a></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td align="center"><a href="http://en.opensuse.org/Wine#Repositories"> > + <img src="{$root}/images/distro/suse.png" width="50" height="50" alt="SUSE Linux" border="0"></a> > + </td> > + <td> <b><a href="http://en.opensuse.org/Wine#Repositories">SUSE</a></b> > + binarne i ¼ród³owe .rpmy i dzienne zrzuty RPM dla openSUSE 10.3, 11.0, 11.1 i SLES 9 i SLE 10.<br/> > + Starsze wersje paczek dostêpne <a href="http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=7…">SourceForge</a> > + </td> > + <td><a href="mailto:meissner(a)suse.de">Marcus Meissner</a></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td align="center"><a href="http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=8…"> > + <img src="{$root}/images/distro/mandriva.png" width="50" height="50" alt="Mandriva Linux" border="0"></a> > + </td> > + <td> <b><a href="http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=8…">Mandriva</a></b> > + binarne .rpmy dla Mandriva Linux 2006, 2007, i 2008. Pobierz > + paczkê 2008.1 je¿eli twoja Mandriva to wydanie 2008.1 , np. 2008 > + Spring. Pobierz paczkê 2008.0 je¿eli twoja Mandriva jest > + pierwszym wydaniem z 2008 roku</td> > + <td><a href="mailto:marco(a)mandrivaclub.nl">Marco Meijer</a></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td align="center"><a href="http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=6…"> > + <img src="{$root}/images/distro/slackware.png" width="50" height="50" alt="Slackware linux" border="0"></a> > + </td> > + <td> <b><a href="http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=6…">Slackware</a></b> > + binarne .tgz dla Slackware 10.2</td> > + <td><a href="mailto:sadam(a)clemson.edu">Adam Schreiber</a></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td align="center"><a href="http://www.freshports.org/emulators/wine/"> > + <img src="{$root}/images/distro/freebsd.png" width="50" height="54" alt="FreeBSD" border="0"></a> > + </td> > + <td> <b><a href="http://www.freshports.org/emulators/wine/">FreeBSD</a></b> > + ¼ród³a dla FreeBSD 5.3 i pó¼niejszych</td> > + <td><a href="mailto:gerald(a)pfeifer.com">Gerald Pfeifer</a></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td align="center"><a href="http://www.pbidir.com/bt/search/?str=wine&search=Search"> > + <img src="{$root}/images/distro/pcbsd.png" width="50" height="50" alt="FreeBSD" border="0"></a> > + </td> > + <td> <b><a href="http://www.pbidir.com/bt/search/?str=wine&search=Search">PC-BSD</a></b> > + binarne paczki .pbi dla PC-BSD (system bazuj±cy na FreeBSD)</td> > + <td><a href="mailto:kris(a)pcbsd.com">Kris Moore</a></td> > + </tr> > + > +</table> > + > + > +<h2 style="margin-bottom: 10px;"><a name="binary"></a>Aplikacje osób trzecich</h2> > + > +<p>Czasami pewne modyfikacje Wine mog± sprawiæ, > +¿e aplikacja bêdzie dzia³aæ, ale z pewnych powodów zmiany te nie > +mog± byæ wcielone do Wine. Stworzono ró¿ne aplikacje (tzw. > +aplikacje osób trzecich), aby pomóc przezwyciê¿yæ niedobory w > +Wine. Aplikacje te s± ca³kowicie niewspierane przez programistów > +Wine, jednak¿e mog± ci siê przydaæ. Aby dowiedzieæ siê wiêcej, > +odwied¼ <a href="http://wiki.winehq.org/ThirdPartyApplications">nasz± > +stronê wiki</a> w poszukiwaniu aplikacji osób trzecich.</p> > + > +<h2><a name="source"></a>Pobieralnia ¼róde³ Wine</h2> > + > +<table border="0" cellpadding="5" cellspacing="1" bgcolor="#EFEFEF"> > + > + <tr> > + <td align="center" bgcolor="black"><b><font color="white" class="small">Po³o¿enie</font></b></td> > + <td align="center" bgcolor="black"><b><font color="white" class="small">Opis</font></b></td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td> <a href="http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=7…" target="_blank">sourceforge.net</a></td> > + <td> Nasza oficjalna strona ¼róde³. </td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td> <a href="http://wiki.winehq.org/GitWine">source.winehq.org/git</a> </td> > + <td> Do najnowszych wydañ rozwojowych. </td> > + </tr> > + > + <tr bgcolor="#ffffff"> > + <td><a href="http://ibiblio.org/pub/linux/system/emulators/wine/">ibiblio.org</a></td> > + <td> Alternatywna strona z oficjalnymi ¼ród³ami i dokumentacj±. </td> > + </tr> > + > +</table> > + > +<div style="margin: 10px; padding: 5px; border: 1px solid #C0C0C0; background-color: #F0F0F0;"><b>Notka:</b> Zobacz <a href="http://wiki.winehq.org/Recommended_Packages">zalecane paczki</a> aby uzyskaæ pomoc przy konfiguracji i kompilacji Wine.</div> > + > + > +<h2><a name="link2us"></a>Link do nas</h2> > + > +<p> > + <a href="http://www.winehq.org/download" target="_blank"><img > + src="{$root}/images/download_wine.png" border="1" width="88" height="31" vspace="0" hspace="5" align="left" > + alt="Download Wine"></a> > + U¿yj tego obrazka je¿eli chcesz utworzyæ dowi±zanie do naszej pobieralni. > +</p> > + > diff --git a/templates/pl/download/deb.template b/templates/pl/download/deb.template > new file mode 100644 > index 0000000..ae03788 > --- /dev/null > +++ b/templates/pl/download/deb.template > @@ -0,0 +1,102 @@ > + > + > + > +<h1 class="title"><a href="http://www.ubuntu.com/" target="_new"><img src="{$root}/images/distro/ubuntu.png" width="50" height="50" alt="Ubuntu Logo" border="0"></a> > +Wine dla Ubuntu i pochodnych Ubuntu > +<a href="http://www.debian.org/" target="_new"><img src="{$root}/images/distro/ubuntu.png" width="50" height="50" alt="Ubuntu Logo" border="0"></a></h1> > + > +<p>Ubuntu i inne dystrybucje bazuj±ce na Debianie > +u¿ywaj± specjalnego narzêdzia zwanego APT do zarz±dzania > +paczkami. APT jest zdolne automagicznie zainstalowaæ wszystkie > +potrzebne zale¿no¶ci dla paczki z programem, jak równie¿ > +utrzymywaæ zawsze najnowsz± wersjê paczki, poprzez przeszukiwanie > +czego¶, co jest znane pod nazw± repozytoria APT. Ubuntu ma swoje > +w³asne repozytorium programów, które zawiera w sobie Wine, > +jednak¿e my utrzymujemy nasze w³asne repozytorium najnowszych > +dostêpnych paczek beta, które mo¿na tutaj pobraæ.</p> > + > +<h2>Uwaga: To s± paczki beta</h2> > + > +<p><i>Te paczki s± paczkami beta. Oznacza to, ¿e > +okresowo mog± cierpieæ z powodu > +<a href="http://wiki.winehq.org/Regression">regresji</a>, a aktualizacja do nich mo¿e popsuæ funkcjonalno¶æ Wine. Je¿eli w > +twoim przypadku ostatnie stabilne wydanie Wine (aktualnie Wine 1.0.1) > +dzia³a, to nie musisz u¿ywaæ paczek beta.</i></p> > + > +<h2>Dodawanie repozytorium APT WineHQ:</h2> > + > +<p>Otwórz ¬ród³a oprogramowania z menu > +<b>System->Administracja->¬ród³a oprogramowania</b>. Nastêpnie przejd¼ na zak³adkê <b>Oprogramowanie osób trzecich</b> i kliknij <b>Dodaj...</b></p> > + > +<img src="{$root}/images/distro/ubuntu-softwaresources1.png" width="531" height="509" alt="System->Administration->Software Sources->Third Party Software" border="0"> > + > +<p>Nastêpnie, <b>wklej jedn± z poni¿szych linijek</b> zale¿nie od wersji twojego systemu.</p> > + > +<p><b>Dla Ubuntu Jaunty (9.04):</b><br> > +<i>deb http://wine.budgetdedicated.com/apt jaunty main #WineHQ - Ubuntu 9.04 "Jaunty Jackalope"</i></p> > +<p><b>Dla Ubuntu Intrepid (8.10):</b><br> > +<i>deb http://wine.budgetdedicated.com/apt intrepid main #WineHQ - Ubuntu 8.10 "Intrepid Ibex"</i></p> > +<p><b>Dla Ubuntu Hardy (8.04):</b><br> > +<i>deb http://wine.budgetdedicated.com/apt hardy main #WineHQ - Ubuntu 8.04 "Hardy Heron"</i></p> > + > +<h2>Przyznanie zaufania repozytorium APT WineHQ i instalowanie Wine:</h2> > + > +<p>Po dodaniu repozytorium, potrzebujesz równie¿ dodaæ > +klucz do tego repozytorium do twojej systemowej listy zaufanych kluczy.</p> > + > +<p><b><a href="http://wine.budgetdedicated.com/apt/Scott%20Ritchie.gpg">Pobierz > +i zapisz klucz Scotta Ritchiego</a></b> (prawy przycisk myszy -> zapisz jako) na pulpicie. Nastêpnie przejd¼ na > +zak³adkê <b>Uwierzytelnianie</b> , kliknij <b>Zaimportuj plik klucza...</b>, i wybierz plik klucza, którego w³a¶nie zapisa³e¶ (<i>Scott Ritchie.gpg</i>). Mo¿esz usun±æ ten plik po wykonaniu tego kroku.</p> > + > +<img src="{$root}/images/distro/ubuntu-softwaresources2.png" width="531" height="509" alt="System->Administration->Software Sources->Authentication" border="0"> > + > +<p>Kliknij zamknij, aby zakoñczyæ, a potem <b>uaktualnij dane o paczkach</b> w > +momencie pytania. Je¿eli masz zainstalowane Wine to systemowy > +menad¿er aktualizacji poinformuje ciê o najnowszym wydaniu Wine > +beta i zapyta ciê o aktualizacjê. Je¿eli nie instalowa³e¶ > +jeszcze Wine, to przejd¼ do <b>Aplikacje->Dodaj/usuñ aplikacje</b> i poszukaj Wine lub po prostu <a href="apt://wine">kliknij na tego > +linka</a>.</p> > + > +<h2>Aktualizacja do nowej wersji Ubuntu</h2> > + > +<p>Je¿eli aktualizujesz ca³y system np. przechodzisz z > +Ubuntu 8.10 na 9.04, to bêdzie konieczny powrót do tej strony i > +dodanie repozytorium do nowej wersji systemu. Wbudowany menad¿er > +aktualizacji nie zmieni automatycznie repozytorium Wine.</p> > + > +<h2>Starsze paczki .deb</h2> > + > +<p>Jako ¿e repozytorium APT mo¿e przechowywaæ > +jedynie najnowsze paczki, tak wiêc starsze wersje paczek s± > +dostêpne w > +<a href="http://wine.budgetdedicated.com/archive/index.html">archiwum WineHQ paczek .deb</a>.</p> > + > +<p>Mo¿esz zainstalowaæ pobrane paczki klikaj±c na nie dwukrotnie.</p> > + > +<h2>Alternatywne komendy wiersza poleceñ do zainstalowania Wine:</h2> > + > +<p>Mo¿liwe jest tak¿e dodanie repozytoriów Wine i > +zainstalowanie go z wiersza poleceñ. Jest to u¿yteczne w przypadku > +Kubuntu, Xubuntu, i innych pochodnych Ubuntu.</p> > + > +<p>Najpierw otwórz okno terminalu <b>Aplikacje->Akcesoria->Terminal</b> . Nastêpnie dodaj klucz > +repozytorium do systemowej listy zaufanych kluczy APT przez wklejenie > +nastêpuj±cej linijki do twojego terminalu:</p> > + > +<p><i>wget -q http://wine.budgetdedicated.com/apt/387EE263.gpg -O- | sudo apt-key add -</i></p> > + > +<p>Nastêpnie, dodaj repozytorium do systemowej listy ¼róde³ APT:</p> > + > +<p><b>Dla Ubuntu Jaunty (9.04):</b><br> > +<i>sudo wget http://wine.budgetdedicated.com/apt/sources.list.d/jaunty.list -O /etc/apt/sources.list.d/winehq.list</i></p> > +<p><b>Dla Ubuntu Intrepid (8.10):</b><br> > +<i>sudo wget http://wine.budgetdedicated.com/apt/sources.list.d/intrepid.list -O /etc/apt/sources.list.d/winehq.list</i></p> > +<p><b>Dla Ubuntu Hardy (8.04):</b><br> > +<i>sudo wget http://wine.budgetdedicated.com/apt/sources.list.d/hardy.list -O /etc/apt/sources.list.d/winehq.list</i></p> > + > +<p>Nastêpnie zaktualizuj informacje o paczkach APT wpisuj±c '<b>sudo apt-get > +update</b>'. . Teraz mo¿esz zainstalowaæ Wine zwyczajnie lub wpisuj±c '<b>sudo apt-get > +install wine</b>' w terminalu.</p> > + > +<br> > +<p><i>Bardzo szybki i niezawodny webhosting dla repozytoriów APT jest ³askawie dostarczany przez <a href="http://www.budgetdedicated.com/">budgetdedicated.com</a>.</i></p> > diff --git a/templates/pl/home.template b/templates/pl/home.template > new file mode 100644 > index 0000000..5687919 > --- /dev/null > +++ b/templates/pl/home.template > @@ -0,0 +1,90 @@ > + > + > + > + > +<div id="main_left"> > + > + <div class="rbox"> > + <b class="rtop"><b class="r1"></b><b class="r2"></b><b class="r3"></b><b class="r4"></b></b> > + <div class="content" style="padding: 25px 10px 10px 60px; height: 445px; overflow: auto;"> > + <ul class="winehq_menu"> > + > + <li class="info" onClick="document.location='{$root}/about/';"> > + <div class="title"><a href="{$root}/about/">Informacje</a></div> > + <div class="subtitle">Przegl±d funkcji Wine.</div> > + </li> > + > + <li class="dl" onClick="document.location='{$root}/download/';"> > + <div class="title"><a href="{$root}/download/">Pobieralnia</a></div> > + <div class="subtitle">¦ci±gnij Wine teraz!</div> > + </li> > + > + <li class="help" onClick="document.location='{$root}/help/';"> > + <div class="title"><a href="{$root}/help/">Pomoc!</a></div> > + <div class="subtitle">Dokumentacja, Wsparcie, i Wiki.</div> > + </li> > + > + <li class="devel" onClick="document.location='{$root}/devel/';"> > + <div class="title"><a href="{$root}/devel/">Rozwój</a></div> > + <div class="subtitle">¬ród³a Wine, Szukanie Robaków, itp.</div> > + </li> > + > + <li class="donate" onClick="document.donateForm.submit();"> > + <form action="https://www.paypal.com/cgi-bin/webscr" method="post" name="donateForm" style="margin: 0; padding: 0;"> > + <div class="title"><a href="javascript:document.donateForm.submit();">Darowizny</a></div> > + <input type="hidden" name="cmd" value="_xclick"> > + <input type="hidden" name="business" value="donate(a)winehq.org"> > + <input type="hidden" name="item_name" value="Wine donation"> > + </form> > + <div class="subtitle">Ofiary dla Wine.</div> > + </li> > + > + </ul> > + </div> > + <b class="rbottom"><b class="r4"></b><b class="r3"></b><b class="r2"></b><b class="r1"></b></b> > + </div> > + > + > +</div> > +<div id="main_right"> > + > + <div class="rbox"> > + <b class="rtop"><b class="r1"></b><b class="r2"></b><b class="r3"></b><b class="r4"></b></b> > + <div class="content" style="padding: 5px 10px 5px 10px; height: 85px; overflow: auto;"> > + > + <h3 class="title" style="margin: 0;">Najnowsze wydania</h3> > + <table style="margin: 7px 0 0 15px; border-spacing: 0; border: 0;"> > + <tr><td>Stabilne:</td> > + <td style="padding-left: 15px; padding-bottom: 2px;"> > + <b><a href="{$root}/announce/{$config_stable_release}">Wine {$config_stable_release}</a></b> > + <span class="small"> > + (<a href="http://source.winehq.org/git/wine.git?a=shortlog;h=refs/tags/wine-{$config_…">zmiany</a>) > + </span> > + </td></tr> > + <tr><td>Rozwojowe:</td> > + <td style="padding-left: 15px;"> > + <b><a href="{$root}/announce/{$config_master_release}">Wine {$config_master_release}</a></b> > + <span class="small"> > + (<a href="http://source.winehq.org/git/wine.git?a=shortlog;h=refs/tags/wine-{$config_…">zmiany</a>) > + </span> > + </td></tr> > + </table> > + </div> > + <b class="rbottom"><b class="r4"></b><b class="r3"></b><b class="r2"></b><b class="r1"></b></b> > + </div> > + > + <div class="rbox" style="margin-top: 15px;"> > + <b class="rtop"><b class="r1"></b><b class="r2"></b><b class="r3"></b><b class="r4"></b></b> > + <div class="content" style="padding: 10px; height: 340px; overflow: auto;"> > + > + <h3 class="title"><a href="{$root}/news/">Aktualno¶ci</a></h3> > + > +  > + > + <p><a href="{$root}/news/">wiêcej aktualno¶ci...</a></p> > + </div> > + <b class="rbottom"><b class="r4"></b><b class="r3"></b><b class="r2"></b><b class="r1"></b></b> > + </div> > + > +</div> > + > diff --git a/templates/pl/interview.template b/templates/pl/interview.template > new file mode 100644 > index 0000000..dc322f4 > --- /dev/null > +++ b/templates/pl/interview.template > @@ -0,0 +1,8 @@ > + > + > + > +<h1 class="title">Wywiady</h1> > + > + > + > + > diff --git a/templates/pl/irc.template b/templates/pl/irc.template > new file mode 100644 > index 0000000..e116f37 > --- /dev/null > +++ b/templates/pl/irc.template > @@ -0,0 +1,18 @@ > + > + > + > +<h1 class="title">Wsparcie na ¿ywo</h1> > + > +<p><a href="http://www.freenode.net">Freenode.net</a> hostuje kana³ IRC dla Wine. Mo¿esz wej¶æ do pokoju rozmów > +u¿ywaj±c programu IRC takiego jak np. > +<a href="http://www.xchat.org/">X-Chat</a>. U¿yj ustawieñ wymienionych poni¿ej.</p> > + > +<blockquote> > + <b>Serwer:</b> irc.freenode.net<br> > + <b>Port:</b> 6667<br> > + <b>Kana³:</b> #winehq<br> > +</blockquote> > + > +<p>Je¿eli u¿ywasz Mozilli lub innej przegl±darki która wspiera <b>u</b>e<b>r</b>e<b>l</b>e IRC, to mo¿esz do³±czyæ do rozmowy klikaj±c na <a href="irc://irc.freenode.net/#winehq">irc://irc.freenode.net/#winehq</a>.</p> > + > +<p> </p> > diff --git a/templates/pl/lang.template b/templates/pl/lang.template > new file mode 100644 > index 0000000..2c16bb2 > --- /dev/null > +++ b/templates/pl/lang.template > @@ -0,0 +1,37 @@ > + > + > + > +<h1 class="title">{$langChange}</h1> > + > + > + > +<p><b>Aktualny jezyk: </b> {$langCur}</p> > + > +<ul style="list-style: none; margin-left: 20px; padding: 0;"> > + > + <li style="background-image: url('{$root}/images/lang/en.png'); background-repeat: no-repeat; padding: 0 0 10px 40px;"> > + <a href="{$root}/lang/en" title="English">English</a> <small>(Angielski)</small> > + </li></a> > + > + <li style="background-image: url('{$root}/images/lang/de.png'); background-repeat: no-repeat; padding: 0 0 10px 40px;"> > + <a href="{$root}/lang/de" title="Deutsch">Deutsch</a> <small>(Niemiecki)</small> > + </li></a> > + > + <li style="background-image: url('{$root}/images/lang/es.png'); background-repeat: no-repeat; padding: 0 0 10px 40px;"> > + <a href="{$root}/lang/es" title="EspaÃ±ol">EspaÃ±ol</a> <small>(Hiszpanski)</small> > + </li> > + > + <li style="background-image: url('{$root}/images/lang/fr.png'); background-repeat: no-repeat; padding: 0 0 10px 40px;"> > + <a href="{$root}/lang/fr" title="FranÃ§ais">FranÃ§ais</a> <small>(Francuski)</small> > + </li> > + > + <li style="background-image: url('{$root}/images/lang/fr.png'); background-repeat: no-repeat; padding: 0 0 10px 40px;"> > + <a href="{$root}/lang/fr" title="FranÃ§ais">Polski</a> > + </li> > + > + <li style="background-image: url('{$root}/images/lang/pt.png'); background-repeat: no-repeat; padding: 0 0 10px 40px;"> > + <a href="{$root}/lang/pt" title="PortuguÃªs">PortuguÃªs</a> <small>(Portugalski)</small> > + </li> > + > +</ul> > + > diff --git a/templates/pl/news.template b/templates/pl/news.template > new file mode 100644 > index 0000000..ce5c53d > --- /dev/null > +++ b/templates/pl/news.template > @@ -0,0 +1,11 @@ > + > + > + > +<h1 class="title">AktualnoÅ›ci</h1> > + > + > + > +<ul class="rss"> > + <li><a href="{$root}/news/rss/">WineHQ News RSS Feed</a></li> > +</ul> > + > diff --git a/templates/pl/search.template b/templates/pl/search.template > new file mode 100644 > index 0000000..c44736b > --- /dev/null > +++ b/templates/pl/search.template > @@ -0,0 +1,26 @@ > + > + > + > +<h1 class="title" style="margin-bottom: 10px;">Wyniki wyszukiwania</h1> > + > +<div id="cse-search-results"></div> > +<script type="text/javascript"> > + $.gglclientCoords = function() { > + var dimensions = {width: 0, height: 0}; > + if (document.documentElement) { > + dimensions.width = document.documentElement.offsetWidth; > + dimensions.height = document.documentElement.offsetHeight; > + } else if (window.innerWidth && window.innerHeight) { > + dimensions.width = window.innerWidth; > + dimensions.height = window.innerHeight; > + } > + return dimensions; > + } > + var googleSearchIframeName = "cse-search-results"; > + var googleSearchFormName = "cse-search-box"; > + var googleSearchFrameWidth = ($.gglclientCoords().width - 250); > + var googleSearchDomain = "www.google.com"; > + var googleSearchPath = "/cse"; > +</script> > +<script type="text/javascript" src="http://www.google.com/afsonline/show_afs_search.js"></script> > + > > > ------------------------------------------------------------------------ > >

May 4, 2009

Re: Severity levels

by Austin English

2009/5/4 James Mckenzie <jjmckenzie51(a)earthlink.net>: > Ben Klein wrote on May 4th: >> >>Final post from me. >> >>2009/5/5 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >>> b) I thought that priority was developer priority and severity was >>> severity for the users. >> >>Nope. Both for the benefit of developers, hence why they're both on bugzilla. >> >> > One question: Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program? This is much different than the priority and severity fields. No, but it is not important for bugzilla. That information belongs in the AppDB, which allows for this, with the application ratings. -- -Austin

May 4, 2009

Re: Severity levels

by Ken Sharp

James Mckenzie wrote: > One question: Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program? This is much different than the priority and severity fields. Yes, here: http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity

May 4, 2009

Re: Severity levels

by James Mckenzie

Ben Klein wrote on May 4th: > >Final post from me. > >2009/5/5 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >> b) I thought that priority was developer priority and severity was >> severity for the users. > >Nope. Both for the benefit of developers, hence why they're both on bugzilla. > > One question: Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program? This is much different than the priority and severity fields. James McKenzie

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Juan Lang

> We have a similar warning already: > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ws2_32/tests/sock.c#l2… That warning is appropriate, because it's testing IPv6, so the warning applies in all cases. The reason I'm objecting in this case is that the warning is printed for any failure, no matter which chain is being checked, yet this condition can only occur on one of the 15 or so chains that are checked. Like I said, I think it's a special case. --Juan

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Austin English

On Mon, May 4, 2009 at 11:54 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >> Would changing it to: >> "CERT_TRUST_IS_UNTRUSTED_ROOT is expected if no trusted root >> certificate is available." >> be better? > > I don't think so. I think this test is a special case, because it > depends on your system's configuration, whereas the other tests should > not. We have a similar warning already: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ws2_32/tests/sock.c#l2… Surely there's some warning we can agree on...currently, it doesn't give the user any hint of what's wrong. As far as they can tell, it is solely a Wine problem, not their system being misconfigured. If a user sees "no Verisign certificate", they'd be more likely to investigate why that is, and fix it (or, if they are installed, file a bug). > Part of me thinks the test could be removed, as it doesn't really > exercise any code path that isn't already exercised with the existing > tests. On the other hand, if the Verisign root CA isn't installed, > iTunes will silently fail to start. I'm not sure which is worse, an > arguably spurious test failure, or silent application failures. Silent application failures are probably worse... -- -Austin

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Juan Lang

> OpenSolaris doesn't have any Verisign root certificates installed by > default, which is the problem there. Yep, I know. > Would changing it to: > "CERT_TRUST_IS_UNTRUSTED_ROOT is expected if no trusted root > certificate is available." > be better? I don't think so. I think this test is a special case, because it depends on your system's configuration, whereas the other tests should not. Part of me thinks the test could be removed, as it doesn't really exercise any code path that isn't already exercised with the existing tests. On the other hand, if the Verisign root CA isn't installed, iTunes will silently fail to start. I'm not sure which is worse, an arguably spurious test failure, or silent application failures. > I'm working on installing Verisign root certificates on OpenSolaris, > give me a couple days... Cool :) --Juan

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Austin English

On Mon, May 4, 2009 at 11:18 AM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Austin, > >> The error is very cryptic...currently only shows up on OpenSolaris and >> FreeBSD (if /usr/ports/security/ca_root_nss isn't installed). It >> apparently also shows up on some Linux distributions that don't ship >> OpenSSL with any certificates. > > While the error may be cryptic, it shows a real bug: we don't support > the correct root certificate location on OpenSolaris. As I said > earlier, adding a warning that isn't applicable most of the time > doesn't seem like an appropriate fix. OpenSolaris doesn't have any Verisign root certificates installed by default, which is the problem there. Would changing it to: "CERT_TRUST_IS_UNTRUSTED_ROOT is expected if no trusted root certificate is available." be better? I'm working on installing Verisign root certificates on OpenSolaris, give me a couple days... -- -Austin

May 4, 2009

RE: Severity levels

by Nicklas Börjesson

>Guys, y'all are going in a circular argument. No need to cc wine-devel >on it anymore. I am rather fed up with it as well, also I will soon not have any more time for it since I'll be going back to work tomorrow. I've had stomach flu(!swine) the last week. Circular? More plain disagreement i'd say. >Let's work toward making normal the default level, and move on with our lives. Yep. Let's do that. Let's aim for the stars. >Any developer/user focus for bugzilla argument is WAY beyond beating a >dead horse. Ok.

May 4, 2009

Re: Severity levels

by IneedAname

On Sun, 3 May 2009 23:31:45 -0400 Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> wrote: > +1. Or just remove priorities for users altogether. Looks like some one is thinking round here! That gets my vote to.

May 4, 2009

Re: Severity levels

by IneedAname

On Mon, 4 May 2009 22:12:04 +1000 Ben Klein <shacklein(a)gmail.com> wrote: > 2009/5/4 Ben Klein <shacklein(a)gmail.com>: > > Then they disappear. There would be no way to search for metabugs, for > > example, whereas at the moment you can search for Blockers. There's no > > point in keeping metabugs if there's no > > SUSPENSE! > > Lost a chunk of line there. > > There's no point in keeping metabugs if there's no way to ... > > SUSPENSE! > > no way to distinguish them from regular bugs. Wine does have meta bugs look at the application data base. Each application has a list of bugs that effect that program. Why Wine does not use meta bugs in bugzilla is because they end up being "Make my all programs work with wine! Now" list.

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Juan Lang

Hi Austin, > The error is very cryptic...currently only shows up on OpenSolaris and > FreeBSD (if /usr/ports/security/ca_root_nss isn't installed). It > apparently also shows up on some Linux distributions that don't ship > OpenSSL with any certificates. While the error may be cryptic, it shows a real bug: we don't support the correct root certificate location on OpenSolaris. As I said earlier, adding a warning that isn't applicable most of the time doesn't seem like an appropriate fix. --Juan

May 4, 2009

Re: crypt32/tests: Print a better error if no Verisign root certificates available.

by Juan Lang

Hi, I just noticed commit efa555596b30134261920ea12d8c324f9bef34b4. This change is misleading: - "Chain %d, element [%d,%d]: expected error %08x, got %08x\n", + "Chain %d, element [%d,%d]: expected error %08x, got %08x. %08x is " + "expected if no valid Verisign root certificate is available.\n", testIndex, chainIndex, elementIndex, expected->dwErrorStatus, - got->dwErrorStatus); + got->dwErrorStatus, CERT_TRUST_IS_UNTRUSTED_ROOT); The only difference is to add CERT_TRUST_IS_UNTRUSTED_ROOT if any chain doesn't match, whatever the reason. On the other hand, only one chain out of 14 or so that are tested would ever unexpectedly have CERT_TRUST_IS_UNTRUSTED_ROOT set. The remainder of the chains are not rooted in any trusted CA, but are rooted in some untrusted cert. So I don't think this change is really all that beneficial. Personally, I'd rather have the change reverted. Comments? --Juan

May 4, 2009

GUI debugging

by Benoit SCHWINDEN

Hello, I am trying to make a very special application working with Wine 1.1.20 (Loris, from Ever Ezida, a library management software). Almost everything is functionnal, but there is a little graphical bug with some texfields. Also, I would like to know if there are some ways to debug a GUI, especially a way to know which library or DLL is called to display a part of this GUI (ie know what DLL is used to display my faulties text fields). Thanks a lot by advance. Best regards, Benoit. -- Benoit SCHWINDEN Direction Informatique Groupe GNU/Linux Université de Strasbourg 03 90 24 12 46

May 4, 2009

Re: Severity levels

by Ben Klein

Final post from me. 2009/5/5 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > b) I thought that priority was developer priority and severity was > severity for the users. Nope. Both for the benefit of developers, hence why they're both on bugzilla.

May 4, 2009

Re: Severity levels

by Austin English

Guys, y'all are going in a circular argument. No need to cc wine-devel on it anymore. Let's work toward making normal the default level, and move on with our lives. Any developer/user focus for bugzilla argument is WAY beyond beating a dead horse. -- -Austin

May 4, 2009

RE: Severity levels

by Nicklas Börjesson

>You're one guy against the world. So far, no one on this thread has >responded positively to your proposal to overhaul severities. I'd >suggest you stop acting like it's an inevitability Ok then. >Once again bugzilla is a developer's tool, not a collection of data >for users. We already have the Wiki, forums and AppDB satisfying the >users' needs. Ok. >Point is that metabugs, though useless to users, are important for the >REAL target audience of bugzilla: developers. >Repeat after me: > Bugzilla is there for the developers, not the users .... Better not let them in then. >A user-centric focus on bug priorities simply would not work with a >project as large (massive?) as Wine is. .... Repeat after me: "Nicklas Is not proposing a user centric focus, which would be insane, he is merely talking about weighing it in." "Nicklas Is not proposing a user centric focus, which would be insane, he is merely talking about weighing it in." I have actually forgot how many times I have tried to say this. >Then they disappear. There would be no way to search for metabugs, for >example, whereas at the moment you can search for Blockers. There's no >point in keeping metabugs if there's no ... I would search for priority 1 bugs. To be a priority 1 bug it would had to had been either a blocker or critial. Metabugs...well, if they are used a lot maybe that will become a problem. But aren't using metabugs a bit wrong anyway? >You're now implying that all bugs should be given equal priority. No I am not. I rarely imply. >Some bugs *can't* be fixed without limitations lifted in other areas (e.g. >introduction of Xinput2). They could still be severe (mouse-related >bugs could easily attain Major severity) but be a low priority due to >forces outside of Wine. Then severity would be critical and priority 4. > Mixing is up like is done now makes it: > a) more complicated for users. b) more difficult to severity in statistics. >a) is not a consideration for bugzilla. It has to be easy for the >developers that respond. >b) is nonsensical. We're talking about two very different forms of >statistics. Bugzilla is the place for developer-side severity (which >is what's in place now); forums and AppDB are the places for user-side >severity (which is what you're suggesting). By definition, there is no >way to gather statistics on one when the other is used. a) You are right. Keep them users out of there. b) I thought that priority was developer priority and severity was severity for the users. >Please quote with context! And having no definitions of the severity >levels is just asking for trouble. Surely you realise that every user >will have a different opinion on how serious their bug is, and what >the boundaries for "Low", "Medium", "High" and "Critical" are, which >will likely vary greatly from what the developers responding to the >bugs think? Conflict between developers and users is bad, and having >real definitions of the severity levels allows the devs to say "well, >your 'Critical' bug that has a simple but tedious workaround doesn't >fit the definition of Critical, so it's being downgraded to 'Minor'." If one say severity is in usage context and priority is in big-picture context there would be less conflicts. >I can't tell what you're talking about here. Ok. The same. >1) "A few years" is rapid? Yes. I'd say so. I a large project's life, anyway. >2) "Drifting away" from usability when we've always (AFAIK) had the >current severity levels (but not necessarily the definitions), and >established that the system works well to assist developers >categorising the bugs? Wine hasn't been used seriously by people until now. When something goes from being only a toy to a real too it brings changes. >3) "Such a small skew", as in handing over full control over what >priority should be given to the bug to the users? And before you say >it's not "full control", if it's not something that will seriously >influence the way bugs are prioritised, it's pointless to do such a >massive overhaul of the severity ratings. Again, I disagree. Massive? Renaming some categorisations? >4) "Normal" getting fixed more than "minor" is a problem? Yes, this can be a huge problem if minor consists of annoyances. In the end, one have a system that works, but in a very annoying way. >Applications still have to be treated on a per-app basis. Every app is >different, and in extreme cases different versions of the same app use >violently different API calls. Yes, but I am talkic >Correct, games and 3D applications do tend to use DirectX, whereas >office applications don't (tend to). Well done, astute observation. It >doesn't mean that a joystick fix for GTA:San Andreas will work with >Gunmetal, or that a WineD3D patch for COD4 will improve performance in >Supreme Commander. They're all individuals! (Chorus: Yes, they're all >individuals!) They're all different! (Chorus: Yes, they're all >different!) (I'm not) (shhh) I think you are just being negative, to be honest. So games aren't more like each others than they are like a word processor? Support forums are normally grouped into areas this way, why can't wine do this? >That's what searching is for. Try searching it for "blockers" then. :-) Splitting would be a rough categorization of threads that I think would be beneficial, that's all.

May 4, 2009

Re: Severity levels

by Paul TBBle Hampson

On Mon, May 04, 2009 at 10:12:04PM +1000, Ben Klein wrote: > 2009/5/4 Ben Klein <shacklein(a)gmail.com>: >> Then they disappear. There would be no way to search for metabugs, for >> example, whereas at the moment you can search for Blockers. There's no >> point in keeping metabugs if there's no > There's no point in keeping metabugs if there's no way to ... > no way to distinguish them from regular bugs. I was under the impression that Wine didn't want metabugs. I'm sure I've seem comments to that effect in Bugzilla itself... -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

May 4, 2009

Re: Severity levels

by Ben Klein

2009/5/4 Ben Klein <shacklein(a)gmail.com>: > Then they disappear. There would be no way to search for metabugs, for > example, whereas at the moment you can search for Blockers. There's no > point in keeping metabugs if there's no SUSPENSE! Lost a chunk of line there. There's no point in keeping metabugs if there's no way to ... SUSPENSE! no way to distinguish them from regular bugs.

May 4, 2009

Re: Severity levels

by Ben Klein

2009/5/4 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > As I wrote in my earlier post, Austin told me about the voting functionality, > and If that is considered when priorities are made, it is likely to keep > things pretty on track, making my proposed changes far less important. > I still think my thoughts aren't that off anyway, but now they feel a > bit more "optional". You're one guy against the world. So far, no one on this thread has responded positively to your proposal to overhaul severities. I'd suggest you stop acting like it's an inevitability Once again bugzilla is a developer's tool, not a collection of data for users. We already have the Wiki, forums and AppDB satisfying the users' needs. >>No, he's proposing to dump the developer-focused severity completely, >>because "component + priority should be good enough", and replace it >>with ill-defined, ambiguous Low, Medium, High, Critical. Blockers and >>metabugs would also disappear under his proposed model, it seems. >>After all, what good are metabugs to users? ;) > > Exactly. Ben's got it. :-) Point is that metabugs, though useless to users, are important for the REAL target audience of bugzilla: developers. Repeat after me: * Bugzilla is there for the developers, not the users * Bugzilla's target audience is the developers, not the users * Bugzilla's target demographic is the developers, not the users * Bugzilla will fly up Tokyo Tower for the developers, not the users * Bugs on bugzilla are examined, responded and fixed to by developers, not users (OK, there are cases where that last one is false, but wherever code is required ...) A user-centric focus on bug priorities simply would not work with a project as large (massive?) as Wine is. > But blockers and metabugs wouldn't disappear. > They would only lose their special classification. Then they disappear. There would be no way to search for metabugs, for example, whereas at the moment you can search for Blockers. There's no point in keeping metabugs if there's no > They would likely have it's priorities set to 1 by the developer reviewing. > In what other way than they are highly prioritized are they different to any other bug? > Something that must be fixed, must be fixed, regardless. You're now implying that all bugs should be given equal priority. Some bugs *can't* be fixed without limitations lifted in other areas (e.g. introduction of Xinput2). They could still be severe (mouse-related bugs could easily attain Major severity) but be a low priority due to forces outside of Wine. > To me, blocker is a class of bugs, not a level of severity. Agreed, Blocker is a class of bugs, but severity is a neat way to keep track of it. You can't have a minor or trivial blocker; all blockers block development in their area. > Mixing is up like is done now makes it: > a) more complicated for users. b) more difficult to severity in statistics. a) is not a consideration for bugzilla. It has to be easy for the developers that respond. b) is nonsensical. We're talking about two very different forms of statistics. Bugzilla is the place for developer-side severity (which is what's in place now); forums and AppDB are the places for user-side severity (which is what you're suggesting). By definition, there is no way to gather statistics on one when the other is used. >>ill-defined > I would go further than I'll-defined. I'd say non-defined. Please quote with context! And having no definitions of the severity levels is just asking for trouble. Surely you realise that every user will have a different opinion on how serious their bug is, and what the boundaries for "Low", "Medium", "High" and "Critical" are, which will likely vary greatly from what the developers responding to the bugs think? Conflict between developers and users is bad, and having real definitions of the severity levels allows the devs to say "well, your 'Critical' bug that has a simple but tedious workaround doesn't fit the definition of Critical, so it's being downgraded to 'Minor'." > The other things I talked about, drifting away from usability is a > fairly rapid process(a few years) that I actually have experienced first hand > (well second hand, actually), and it wasn't pretty. > You joke about it, but the worst thing about it is that because it really only > needs such a small skew to happen, it creeps up on you. > Because "normal" get fixed far more often than "minor" bugs. I can't tell what you're talking about here. 1) "A few years" is rapid? 2) "Drifting away" from usability when we've always (AFAIK) had the current severity levels (but not necessarily the definitions), and established that the system works well to assist developers categorising the bugs? 3) "Such a small skew", as in handing over full control over what priority should be given to the bug to the users? And before you say it's not "full control", if it's not something that will seriously influence the way bugs are prioritised, it's pointless to do such a massive overhaul of the severity ratings. 4) "Normal" getting fixed more than "minor" is a problem? >> Firefox and IE have drastically different success/failure/issues >> when running in Wine, as do MS Word and >> WordPerfect > > Yep, but I'd rather put I it like a Microsoft application has often other problems than externally developed applications(built-in vs using dll:s for everything). Applications still have to be treated on a per-app basis. Every app is different, and in extreme cases different versions of the same app use violently different API calls. > Anyway, looking at the forums now, games and 3d applications DO usually have different issues than normal desktop applications. > It's more about controllers, DirectX and other stuff. Correct, games and 3D applications do tend to use DirectX, whereas office applications don't (tend to). Well done, astute observation. It doesn't mean that a joystick fix for GTA:San Andreas will work with Gunmetal, or that a WineD3D patch for COD4 will improve performance in Supreme Commander. They're all individuals! (Chorus: Yes, they're all individuals!) They're all different! (Chorus: Yes, they're all different!) (I'm not) (shhh) > And there are a LOT of posts. 30 new threads the last 24 hours. Lot's to wade through I you're only into D3D issues. > If it was different lists, people could become a little bit more specialized. That's what searching is for.

May 4, 2009

RE: Severity levels

by Nicklas Börjesson

>Just changing the default to normal should solve a lot of the problem; people are less likely to change the severity level if the one they're >presented with looks reasonable. I think so too. Especially if the selected one, "enhancement" almost certainly is wrong. >I know what Major and Critical mean too, but I can live without being able to make that change myself if restricting it will help. There's always >the comment field to state an opinion. I agree here as well. I would also rename "trivial" to "low", "minor" to "medium" and "normal" to "high". *ducks* //Nicklas -----Original Message----- From: wine-devel-bounces(a)winehq.org on behalf of Rosanne DiMesio Sent: Mon 2009-05-04 13:39 To: Austin English Cc: wine-devel(a)winehq.org Subject: Re: Severity levels On Mon, 4 May 2009 00:31:09 -0500 Austin English <austinenglish(a)gmail.com> wrote: > > > > But how would the restriction work? Not that I'm likely to ever submit > > a Major or Critical bug report, but I know what they mean ;) > > > > I don't know if bugzilla supports that or not. > > But changing the default to normal is quick and easy. > > -- Just changing the default to normal should solve a lot of the problem; people are less likely to change the severity level if the one they're presented with looks reasonable. I know what Major and Critical mean too, but I can live without being able to make that change myself if restricting it will help. There's always the comment field to state an opinion. -- Rosanne DiMesio <dimesio(a)earthlink.net>

May 4, 2009

Re: Severity levels

by Rosanne DiMesio

On Mon, 4 May 2009 00:31:09 -0500 Austin English <austinenglish(a)gmail.com> wrote: > > > > But how would the restriction work? Not that I'm likely to ever submit > > a Major or Critical bug report, but I know what they mean ;) > > > > I don't know if bugzilla supports that or not. > > But changing the default to normal is quick and easy. > > -- Just changing the default to normal should solve a lot of the problem; people are less likely to change the severity level if the one they're presented with looks reasonable. I know what Major and Critical mean too, but I can live without being able to make that change myself if restricting it will help. There's always the comment field to state an opinion. -- Rosanne DiMesio <dimesio(a)earthlink.net>

May 4, 2009

Re: Romanian translation (again)

by Michael Stefaniuc

Hello Dumitriu, Dimitriu Petru wrote: > I'm here again for the Romanian translation of Wine. > I only want somebody to change in the translation "Proprietă?i pentru" > with "Proprietăţi pentru" because it shows ugly in ReactOS. That change is wrong as the correct glyph to use is "t with comma below accent" and that is what Wine already uses. You just need better/newer fonts in ReactOS. The Wine fonts have the needed glyphs as I have added them. If your fonts to have the comma below glyphs the problem could be that you are using an ASCII codepage on ReactOS for Romanian. That won't work and you need to use Unicode. But you will have the exact same problem on Windows too as the Windows bestfit mappings don't handle s and t with comma below accent. See also http://bugs.winehq.org/show_bug.cgi?id=17789 bye michael

May 4, 2009

Re: comdlg32: fix romanian translation

by Michael Stefaniuc

André Hentschel wrote: > suggested by Dimitriu Petru > --- > dlls/comdlg32/cdlg_Ro.rc | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) This patch is wrong. The Romanian language uses "ț" aka "t with comma below accent" and not "ţ" which is "t with cedilla". bye michael

May 4, 2009

GUI debugging

by Benoit SCHWINDEN

Hello, I am trying to make a very special application working with Wine 1.1.20 (Loris, from Ever Ezida, a library management software). Almost everything is functionnal, but there is a little graphical bug with some texfields. Also, I would like to know if there are some ways to debug a GUI, especially a way to know which library or DLL is called to display a part of this GUI (ie know what DLL is used to display my faulties text fields). Thanks a lot by advance. Best regards, Benoit. -- Benoit SCHWINDEN Direction Informatique Groupe GNU/Linux Université de Strasbourg 03 90 24 12 46

May 4, 2009

Re: Giving up for now

by Joel Holdsworth

On Sun, 2009-05-03 at 16:05 +0200, Roderick Colenbrander wrote: > We do support some alpha support using XRender, can't you use this > too? I think that's the general method for using alpha at the moment > on X. Yes and I'm using GdiAlphaBlend - for rendering, and I have fixes to use it. It's what you need to enable DrawIcon and DrawIconEx to draw properly. The reason is to do with the way *loading* works. Icons get loaded in arbitrary sizes and colour depths, but of course only compatible HBITMAPs can be displayed e.g. a 4-bit icon has to be upsampled to 32-bit before it can be displayed on my system. As a solution to both these problems CURSORICON_CreateIconFromBMI has an internal call to StretchDIBits, which applies both depth and size conversions. The problem is that this call seems to loose the alpha channel in doing so. I guess I should write a test to find out what StretchDIBits *should* do - whether we can use it, even theoretically. Once we get to the stage of returning a full formed HICON to the app, it's plain sailing. My DrawIcon patch can render alpha channel icons no problem, and hopefully a DrawIconEx patch will soon follow. The problem is that the only way to create one in wine right now is with CreateIcon! Joel

May 4, 2009

RE: Severity levels

by Nicklas Börjesson

As I wrote in my earlier post, Austin told me about the voting functionality, and If that is considered when priorities are made, it is likely to keep things pretty on track, making my proposed changes far less important. I still think my thoughts aren't that off anyway, but now they feel a bit more "optional". >No, he's proposing to dump the developer-focused severity completely, >because "component + priority should be good enough", and replace it >with ill-defined, ambiguous Low, Medium, High, Critical. Blockers and >metabugs would also disappear under his proposed model, it seems. >After all, what good are metabugs to users? ;) Exactly. Ben's got it. :-) But blockers and metabugs wouldn't disappear. They would only lose their special classification. They would likely have it's priorities set to 1 by the developer reviewing. In what other way than they are highly prioritized are they different to any other bug? Something that must be fixed, must be fixed, regardless. To me, blocker is a class of bugs, not a level of severity. Mixing is up like is done now makes it: a) more complicated for users. b) more difficult to severity in statistics. >ill-defined I would go further than I'll-defined. I'd say non-defined. The other things I talked about, drifting away from usability is a fairly rapid process(a few years) that I actually have experienced first hand (well second hand, actually), and it wasn't pretty. You joke about it, but the worst thing about it is that because it really only needs such a small skew to happen, it creeps up on you. Because "normal" get fixed far more often than "minor" bugs. > Firefox and IE have drastically different success/failure/issues > when running in Wine, as do MS Word and > WordPerfect Yep, but I'd rather put I it like a Microsoft application has often other problems than externally developed applications(built-in vs using dll:s for everything). Anyway, looking at the forums now, games and 3d applications DO usually have different issues than normal desktop applications. It's more about controllers, DirectX and other stuff. And there are a LOT of posts. 30 new threads the last 24 hours. Lot's to wade through I you're only into D3D issues. If it was different lists, people could become a little bit more specialized. //Nicklas

May 4, 2009

Re: Severity levels

by Austin English

On Mon, May 4, 2009 at 12:28 AM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/5/4 Austin English <austinenglish(a)gmail.com>: >> 2009/5/3 Rosanne DiMesio <dimesio(a)earthlink.net>: >>> What I would suggest is making the default severity normal rather than enhancement, as that's what's appropriate in most cases anyway (and there's already a bug report, 13363, suggesting just that), and perhaps allowing users to lower the severity if they want. Judgments about raising the severity level above normal should be restricted to the people who know what they're doing. >> >> +1 > > +1 > > But how would the restriction work? Not that I'm likely to ever submit > a Major or Critical bug report, but I know what they mean ;) > I don't know if bugzilla supports that or not. But changing the default to normal is quick and easy. -- -Austin

May 4, 2009

Re: Severity levels

by Ben Klein

2009/5/4 Austin English <austinenglish(a)gmail.com>: > 2009/5/3 Rosanne DiMesio <dimesio(a)earthlink.net>: >> What I would suggest is making the default severity normal rather than enhancement, as that's what's appropriate in most cases anyway (and there's already a bug report, 13363, suggesting just that), and perhaps allowing users to lower the severity if they want. Judgments about raising the severity level above normal should be restricted to the people who know what they're doing. > > +1 +1 But how would the restriction work? Not that I'm likely to ever submit a Major or Critical bug report, but I know what they mean ;)

May 4, 2009

Re: Severity levels

by Austin English

2009/5/3 Rosanne DiMesio <dimesio(a)earthlink.net>: > What I would suggest is making the default severity normal rather than enhancement, as that's what's appropriate in most cases anyway (and there's already a bug report, 13363, suggesting just that), and perhaps allowing users to lower the severity if they want. Judgments about raising the severity level above normal should be restricted to the people who know what they're doing. +1 -- -Austin

May 4, 2009

Re: Severity levels

by Rosanne DiMesio

> > > > Let's try user education. You only get to choose normal and we get to > > up/downgrade until you can prove that you know how to do it right. This > > is how some companies do it. > > > > James McKenzie > > > > +1. Or just remove priorities for users altogether. > I think you mean severity. I agree that users should be limited in what severity level they can set, but I suspect that not allowing them to set severity at all would create too much work for the people who would have to go in and set the severity level for every bug filed. What I would suggest is making the default severity normal rather than enhancement, as that's what's appropriate in most cases anyway (and there's already a bug report, 13363, suggesting just that), and perhaps allowing users to lower the severity if they want. Judgments about raising the severity level above normal should be restricted to the people who know what they're doing. Rosanne DiMesio <dimesio(a)earthlink.net>

May 4, 2009

Re: Severity levels

by Mike Kaplinskiy

2009/5/3 James McKenzie <jjmckenzie51(a)earthlink.net>: > Ken Sharp wrote: >> >> >> Nicklas Börjesson wrote: >> >>> I think that the users should have quite a say with regards to how >>> important a bug is, because for every user putting in the >>> (considerable for a user) effort of reporting a bug, there are dozens >>> that don't say anything at all. >> >> To every Wine user, their application not working is critical. This >> is clear by all the bugs that are logged incorrectly every day, >> because nobody bothered reading the FAQ. > You bet. "The application that I reported, which has a perfectly good > Linux port, has to be fixed absolutely last week." I've seen this in > the user list again and again. It gets boorish after a while. > > Let's try user education. You only get to choose normal and we get to > up/downgrade until you can prove that you know how to do it right. This > is how some companies do it. > > James McKenzie > > > > +1. Or just remove priorities for users altogether.

May 4, 2009

Re: Severity levels

by James McKenzie

Ken Sharp wrote: > > > Nicklas Börjesson wrote: > >> I think that the users should have quite a say with regards to how >> important a bug is, because for every user putting in the >> (considerable for a user) effort of reporting a bug, there are dozens >> that don't say anything at all. > > To every Wine user, their application not working is critical. This > is clear by all the bugs that are logged incorrectly every day, > because nobody bothered reading the FAQ. You bet. "The application that I reported, which has a perfectly good Linux port, has to be fixed absolutely last week." I've seen this in the user list again and again. It gets boorish after a while. Let's try user education. You only get to choose normal and we get to up/downgrade until you can prove that you know how to do it right. This is how some companies do it. James McKenzie

May 4, 2009

Re: Office 2007 MSI Crash - Null dereference @ MsiViewExecute

by Mike Kaplinskiy

On Sun, May 3, 2009 at 10:36 PM, James Hawkins <truiken(a)gmail.com> wrote: > On Sun, May 3, 2009 at 1:52 PM, Mike Kaplinskiy > <mike.kaplinskiy(a)gmail.com> wrote: >> On Thu, Apr 30, 2009 at 1:08 PM, James Hawkins <truiken(a)gmail.com> wrote: >>> On Thu, Apr 30, 2009 at 4:03 AM, Austin English <austinenglish(a)gmail.com> wrote: >>>> On Tue, Apr 28, 2009 at 9:27 PM, Mike Kaplinskiy >>>> <mike.kaplinskiy(a)gmail.com> wrote: >>>>> I was looking at the trace of the crash from bug 17600, and it looks like >>>>> a custom action is calling MsiViewExecute with a null hRec. >>>>> >>>>> I (sadly) don't know much about the wine MSI architecture, but the >>>>> msiobj_lock on line 484 should fail since rec will never be fetched >>>>> (null). I think the intention was to make it query->hdr (as it is >>>>> released later). >>>> >>>> A testcase for it would show if you're right or wrong ;-). >>>> >>> >>> Not really. If you grep through the msi tests, you'll see that we >>> call MsiViewExecute with NULL hRec all over the place. That doesn't >>> mean there isn't a bug, just saying. >>> >>> -- >>> James Hawkins >>> >> >> So I got a little time to look into this, and was completely blown >> away. Apparently doing >> >> TRACE("dereferencing 0?=%p\n", (void *) &(((MSIRECORD *) NULL)->hdr)); >> >> works, since nothing ever gets dereferenced. I will post a patch for >> this small nit. >> >> On a slightly different note, I have traced the problem in office 2007 >> to the patch by James, and in particular to INSERT_execute. The row >> index gets set to 0 if the primary key is null (which is what office >> install is doing), but if the insert is temporary TABLE_insert assumes >> that row >= tv->table->row_count, and subtracts from the row index, >> putting us in the negatives (or high positives due to uint). >> >> I have a patch for this, but I don't know how to make a testcase (all >> I know is office installs), so would anyone mind pointing me to >> somewhere that explains msi temporary inserts? >> >> And should I post the patch up on wine-patches to get it critiqued? >> (sorry, first time) >> > > I'll take a look at your patch. No offense intended, but it's > probably not correct. The problem is a beast and deeply rooted in the > way we store temporary rows in the DB. I have a huge test patch for > it, and I had a fix, but my linux HD got fragged (bummer). > > -- > James Hawkins > (Sorry, forgot to forward to the list) Thanks James. I'm not gonna post it on the patches list quiet yet then. I checked that the msi tests pass with the patch as well. Mike.

May 4, 2009

Re: Office 2007 MSI Crash - Null dereference @ MsiViewExecute

by James Hawkins

On Sun, May 3, 2009 at 1:52 PM, Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> wrote: > On Thu, Apr 30, 2009 at 1:08 PM, James Hawkins <truiken(a)gmail.com> wrote: >> On Thu, Apr 30, 2009 at 4:03 AM, Austin English <austinenglish(a)gmail.com> wrote: >>> On Tue, Apr 28, 2009 at 9:27 PM, Mike Kaplinskiy >>> <mike.kaplinskiy(a)gmail.com> wrote: >>>> I was looking at the trace of the crash from bug 17600, and it looks like >>>> a custom action is calling MsiViewExecute with a null hRec. >>>> >>>> I (sadly) don't know much about the wine MSI architecture, but the >>>> msiobj_lock on line 484 should fail since rec will never be fetched >>>> (null). I think the intention was to make it query->hdr (as it is >>>> released later). >>> >>> A testcase for it would show if you're right or wrong ;-). >>> >> >> Not really. If you grep through the msi tests, you'll see that we >> call MsiViewExecute with NULL hRec all over the place. That doesn't >> mean there isn't a bug, just saying. >> >> -- >> James Hawkins >> > > So I got a little time to look into this, and was completely blown > away. Apparently doing > > TRACE("dereferencing 0?=%p\n", (void *) &(((MSIRECORD *) NULL)->hdr)); > > works, since nothing ever gets dereferenced. I will post a patch for > this small nit. > > On a slightly different note, I have traced the problem in office 2007 > to the patch by James, and in particular to INSERT_execute. The row > index gets set to 0 if the primary key is null (which is what office > install is doing), but if the insert is temporary TABLE_insert assumes > that row >= tv->table->row_count, and subtracts from the row index, > putting us in the negatives (or high positives due to uint). > > I have a patch for this, but I don't know how to make a testcase (all > I know is office installs), so would anyone mind pointing me to > somewhere that explains msi temporary inserts? > > And should I post the patch up on wine-patches to get it critiqued? > (sorry, first time) > I'll take a look at your patch. No offense intended, but it's probably not correct. The problem is a beast and deeply rooted in the way we store temporary rows in the DB. I have a huge test patch for it, and I had a fix, but my linux HD got fragged (bummer). -- James Hawkins

May 4, 2009

Re: Severity levels

by Ben Klein

2009/5/4 Austin English <austinenglish(a)gmail.com>: > 2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >>>Why should there be multiple support forums? >> >> Well, not forums, but as I said different lists for different kinds >> of applications(games/business/graphics), since they should(?) have related problems. >> I would think so, anyway. That would be the case if *everyone* who *ever* produced software banded together and established a one-way-to-do-one-thing API set. Doesn't happen that way. Firefox and IE have drastically different success/failure/issues when running in Wine, as do MS Word and WordPerfect (I bet you thought I was going to say OOWriter!) > The forums seem to serve this well as is. Also AppDB has a browse feature, and lists bugs that apply to each application (when moderated correctly). >>>The wiki has _a lot_ of info, most of the time when bugs are closed invalid, >>>wiki links are given to fix the problem. Again, wine _is_ an open source project. >>> If the wiki isn't good enough, add something. >> >> I am talking about avoiding a bug being submitted at all. By making the bug reporting system more confusing? >> Maybe to organize how-to-run information. >> Sure I could do a bit of that. It's like the idea you had about getting funding, >> did they tell you to go do it all by yourself? > > http://appdb.winehq.org ? > >>>How do you mean their priorities are important? It's an uncomfortable >>>truth, but users priorities aren't important, like has been said >>>dozens of times. Sure, we care about user's bugs, and want to fix >>>them. >> ... >> Users priorities probably affect what severity level they choose. >> But as I said to Ken, I can't believe that all users are morons. >> Anyway, regardless of their motives, I still think that they have to be included. User priorities do not affect which bug should be examined first. All bugs are created equal (and some bugs are more equal than others). Not really the case there, but all bugs of each severity (this is developer-side severity) are created equal and should be treated as such. > It doesn't affect anything, so there is no point. We can give every > user a gold star and say "yes, it's our highest priority", but it > doesn't do anything, so _there is no_ point. > >> If not, the project will slowly drift away and turn into a toy nobody have any use for. > > I highly doubt Wine is going to become irrelevant because users have > their bugs reassigned from critical to normal... You'd be surprised! Releases will stop, AJ will quit citing user unfriendliness, the Earth will spin off its axis and throw everyone save John Smith from Liverpool out in to space, and so forth, all because MY BUG WAS REDUCED FROM CRITICAL TO NORMAL! It's critical to me, so why is it not critical to the developers? </sarcasm> >>>But every user also thinks *their* app is the most important >>>application to fix. >> >> Actually, I can't believe they all are that way. > > Again, you may not think it, but I've been triaging bugs for 3 years, > so I know what does happen. Maybe you should have said "the average user" instead of "every user", but it's true. If we leave the severity level up to the user, we'll get a whole lot of Critical bugs being submitted that aren't critical on the developer's side. >>>Wine can't stop development on _everything_ just to get one user's >>>application running. Making user's arbitrary priorities the most >>>important would be doing this. >> >> Good thing I didn't propose that then. :-) >> I said it should be a part of the priority and a considerable one. Not the largest one. So where should it sit exactly? In between "how long will this take to code" and "how many apps does this effect"? Should it be higher than "is there a simple, *correct* way to fix this"? >> And I am not talking about users arbitrary priorities, just including >> more intuitive severity levels(good or bad) when making bug fixing priorities. So, you mean allow the users to arbitrarily select whether THEY think their bug should have a high priority or not? > I think this argument is circular...Wine has no shortage of bugs being > reported, we have plenty of new users reporting bugs, and new > developers contributing often. You're proposing adding an extra > severity rating that no developer will look at, and will only add to > confusion (users now have to decide *two* levels rather than one). No, he's proposing to dump the developer-focused severity completely, because "component + priority should be good enough", and replace it with ill-defined, ambiguous Low, Medium, High, Critical. Blockers and metabugs would also disappear under his proposed model, it seems. After all, what good are metabugs to users? ;) > It > won't add any benefit, other than possibly giving users a warm fuzzy > feeling that their bug is 'important' to them (which they can already > do with voting), but adds confusion, wasted time, and wasted effort. +1

May 4, 2009

Re: Severity levels

by Ben Klein

2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > It just feels like the entire project should become a bit more user-centric. > Now I am not just talking about shinier graphics but about attitude. Bugzilla not user tool. Bugzilla developers' tool. Bugzilla need work like developers want. 2009/5/4 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >>So you suggest making the severity ratings meaningless to anyone but >>... well, you don't actually mention anyone knowing what they *really* >>mean, but I assume an exclusive clique of developers or bugzilla >>admins? Users have different opinions on what level of bug they >>encounter depending on what *task* they're trying to perform, which is >>not particularly useful to developers who need strict reproducability. > > No, I mean that the actual meaning of the words "low", "medium", "high" and "Critical" will suffice. No they won't. In order for the severity levels to be meaningful, they need to be strictly defined. Take the example of contracts or legislation, where otherwise unambiguous words are defined in context just to make it 100% perfectly clear what's being talked about. Wine is a *big* project, and we really don't need massive confusion over what the severity levels mean. > I think most people have a fair understanding what "medium" and "critical" means. Apparently not. Most people don't see the bigger picture, they only see what they're doing right now (e.g. Critical bugs filed because they have an assignment due the next day when it is in fact only a Minor or Normal bug). > This is not meaningless at all, to trying to clarify these levels is quite pointless though. OK, so give examples of what would be "low", "medium", "high" and "critical" bugs. > Yes, some people tend to exaggerate their issues, but that's just the way it is. And removing the definitions can in no way help this. > And to my experience, they are few. Most actually don't exaggerate as much. So you're suggesting to completely overhaul the system for only a FEW users to be more productive in submitting bugs? > To them, the situation IS critical, bordering on panic. > Rather, thinking that their users are exaggerating is a way for developers to not let reality come to close. > Hell, I do it myself right now. :-) Yes, but that's not what the "severity" indicates. As it has already been said, focusing on a particular user's problem just because THEY think it's critical is completely unproductive for a large (massive?) project like Wine. Wine devs need to look at the big picture, as in "What is the overall impact of this bug? Who and what is affected? Roughly how many applications does it affect/break?" and THAT's what the "severity" setting is for. Another way to look at severity is a rough indication of how much code change is expected to be required to fix the bug. In theory (but by no means in all cases in practice), a Minor bug should have very little code changed compared to a Major bug. Again, severity is there for the *developers* to use and understand, not for the users. > I don't see how the reproducibility connects to the severity level? It doesn't. It connects to the interaction between user and developer. You're talking about user impressions - "THIS NEEDS TO BE FIXED NOW OR I WILL DIE" - I'm talking about REAL bug report information - "When you click on this button then hit this menu option, the application draws squiggly lines all over the screen. Graphics card has nVidia 180.29 drivers." > Regarding the priority flag..i was referring to it's visibility, not its state. Bugzilla doesn't (and can't) know the difference between an average non-tech-savvy user and a hard-core developer. If the priority flag is hidden from average users because they shouldn't change it, then it will also be hidden from people who know how to use it properly, and more importantly the people who NEED to change it (to make their report complete). >>There already is a separate category flag. It's called "severity" and >>it indicates roughly the amount of *functionality* lost due to the >>bug. "Priority" does not indicate the severity of a bug; a bug may >>have low priority due to limitations outside of Wine (such as some >>blocker bugs for copy-protection systems which can't be supported in >>Wine). > > My point is that there should be no need for that flag. > Let the users have it as input, and let the developers use component+priority. Component + priority gives absolutely no indication on the overall impact of a bug, as I have mentioned before. Priority and severity (developer-side severity) do not have a 1-to-1 relationship. >>You're not going to like this, but users don't matter quite *that* >>much on bugzilla. The bug tracker is a developer's tool, and although >>users are essential to the process (submitting bugs and new >>information on request), it should be designed as a developer's tool. >>A user's impression of their problem is irrelevant to the hard data >>they can provide about lost or missing functionality. > > You are right. I don't like it. Called it! > Especially because the bug tracker is the entire projects tool, not only the developers. Who runs the project? Developers. Who fixes bugs with committed code? Developers. Who uses bugzilla the most? Developers (most bugs come from users, but developers are the ones who respond to them). What type of project is the Wine project? Software *development*. We're not in customer service, and even if we were, the bug tracker would be pretty much the same. > I this matter can only compare with my own professional(commercial) experience and there, > the ones submitting bugs has a *lot* to say, since they won't submit bugs unless they are > critical if we don't present them with a smooth interface. I don't see this happening now. Do you? >From what I've seen of the software industry, a lot of companies have a customer service system that feeds reports into a bug tracker that is closed to the public (i.e. for developers only). Wine is a bit different because the bug tracker is open to the public. Why? Because anyone can submit a patch; anyone can become a developer; anyone can propose a solution or report a problem. > Hmm..only critical bugs..now where have i heard about that..? :-) Where HAVE you heard about that? Oh, I remember, when you *remove common sense* from the equation, suddenly all bugs become either Enhancement or Critical, depending on the level of arrogance. Sorry, but we don't take our users for idiots. We assume they have common sense, and so far it's been working very well. Ever heard the old saying, "If it ain't broke, don't fix it"? Either find some statistics to support your claims that bugzilla needs an overhaul, or stop trying to "fix" a working system. 2009/5/4 Ken Sharp <kennybobs(a)o2.co.uk>: > IneedAname wrote: >> >> On Sun, 03 May 2009 18:10:03 +0100 >> Ken Sharp <kennybobs(a)o2.co.uk> wrote: >> >>> That would be the "Show Apps affected by this bug" link then. >>> http://appdb.winehq.org/viewbugs.php?bug_id=16281 >> >> Thanks I missed that so how but my first point still stands. >> > > Not really. 16281 certainly isn't a major loss of functionality, no matter > how many bugs are attached to it. Apart from the minor loss of functionality thing, I don't count that as a "wide range" of applications. There's a couple of "different version of the same game" there (demo vs retail), as well as multiple games in the same series (such as C&C or LotR). Looks to me like a "wide range" of applications don't use .ANI (which is a very good idea. .ANI is horrible! :D).

May 4, 2009

RE: Severity levels

by Nicklas Börjesson

>I think this argument is circular...Wine has no shortage of bugs being >reported, we have plenty of new users reporting bugs, and new >developers contributing often. You're proposing adding an extra >severity rating that no developer will look at, and will only add to >confusion (users now have to decide *two* levels rather than one). It >won't add any benefit, other than possibly giving users a warm fuzzy >feeling that their bug is 'important' to them (which they can already >do with voting), but adds confusion, wasted time, and wasted effort. Yes the voting! I had forgot about that! Actually that pretty much...lessens many of my previous arguments. Well, turns the into moot, really. I still think that the severity levels could be better with regards to UE though, but that seems less important now with the at least theorethical "me too"-power of voting. Again, sorry for taking your time. Too bad nobody mentioned the voting earlier. //Nicklas PS. I never proposed an extra severity flag, but to change it into something more intuitive for the user. I speculated that classification of bugs could be made anyway. DS.

May 3, 2009

Re: Severity levels

by Austin English

2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >>Why should there be multiple support forums? > > Well, not forums, but as I said different lists for different kinds > of applications(games/business/graphics), since they should(?) have related problems. > I would think so, anyway. The forums seem to serve this well as is. >>The wiki has _a lot_ of info, most of the time when bugs are closed invalid, >>wiki links are given to fix the problem. Again, wine _is_ an open source project. >> If the wiki isn't good enough, add something. > > I am talking about avoiding a bug being submitted at all. > Maybe to organize how-to-run information. > Sure I could do a bit of that. It's like the idea you had about getting funding, > did they tell you to go do it all by yourself? http://appdb.winehq.org ? >>How do you mean their priorities are important? It's an uncomfortable >>truth, but users priorities aren't important, like has been said >>dozens of times. Sure, we care about user's bugs, and want to fix >>them. > ... > Users priorities probably affect what severity level they choose. > But as I said to Ken, I can't believe that all users are morons. > Anyway, regardless of their motives, I still think that they have to be included. It doesn't affect anything, so there is no point. We can give every user a gold star and say "yes, it's our highest priority", but it doesn't do anything, so _there is no_ point. > If not, the project will slowly drift away and turn into a toy nobody have any use for. I highly doubt Wine is going to become irrelevant because users have their bugs reassigned from critical to normal... >>But every user also thinks *their* app is the most important >>application to fix. > > Actually, I can't believe they all are that way. Again, you may not think it, but I've been triaging bugs for 3 years, so I know what does happen. >>Wine can't stop development on _everything_ just to get one user's >>application running. Making user's arbitrary priorities the most >>important would be doing this. > > Good thing I didn't propose that then. :-) > I said it should be a part of the priority and a considerable one. Not the largest one. > And I am not talking about users arbitrary priorities, just including > more intuitive severity levels(good or bad) when making bug fixing priorities. I think this argument is circular...Wine has no shortage of bugs being reported, we have plenty of new users reporting bugs, and new developers contributing often. You're proposing adding an extra severity rating that no developer will look at, and will only add to confusion (users now have to decide *two* levels rather than one). It won't add any benefit, other than possibly giving users a warm fuzzy feeling that their bug is 'important' to them (which they can already do with voting), but adds confusion, wasted time, and wasted effort. -- -Austin

May 3, 2009

RE: Severity levels

by Nicklas Börjesson

>>> How many times does this have to be repeated? Severity levels are NOT >>> determined by how much a user wants the app to work. They're just not, >>> deal with it. >> >> I have never said it is, either. >> I said it think it should be determined by how severe the user thinks >> it is(if devs then cares about it is another matter). >And you've already been told it shouldn't, and this has been explained >to you. ><snip waffle> >Junk. Explained to me?? ...this is just incredible. Regardless of what I have said, you have repeated almost the same things, it's like you haven't been reading my posts! Leave me alone, I want to talk to someone else. //Nicklas

May 3, 2009

RE: Severity levels

by Nicklas Börjesson

>Why should there be multiple support forums? Well, not forums, but as I said different lists for different kinds of applications(games/business/graphics), since they should(?) have related problems. I would think so, anyway. >The wiki has _a lot_ of info, most of the time when bugs are closed invalid, >wiki links are given to fix the problem. Again, wine _is_ an open source project. > If the wiki isn't good enough, add something. I am talking about avoiding a bug being submitted at all. Maybe to organize how-to-run information. Sure I could do a bit of that. It's like the idea you had about getting funding, did they tell you to go do it all by yourself? >How do you mean their priorities are important? It's an uncomfortable >truth, but users priorities aren't important, like has been said >dozens of times. Sure, we care about user's bugs, and want to fix >them. ... Users priorities probably affect what severity level they choose. But as I said to Ken, I can't believe that all users are morons. Anyway, regardless of their motives, I still think that they have to be included. If not, the project will slowly drift away and turn into a toy nobody have any use for. >But every user also thinks *their* app is the most important >application to fix. Actually, I can't believe they all are that way. When I first posted a bug here on bugzilla some time ago, one of the first thing I got was you telling me that "there are other applications just as important as yours". The reason in my case was that I completely misunderstood the severity instructions (I had the flu so I was a bit hazy) and mixed it up with the priority instructions. I got going on your comment that Photoshop was not more critical than any other application, which I a far cry from getting pissed of about something with really few users. >Wine can't stop development on _everything_ just to get one user's >application running. Making user's arbitrary priorities the most >important would be doing this. Good thing I didn't propose that then. :-) I said it should be a part of the priority and a considerable one. Not the largest one. And I am not talking about users arbitrary priorities, just including more intuitive severity levels(good or bad) when making bug fixing priorities. //Nicklas

May 3, 2009

Re: Severity levels

by Ken Sharp

Nicklas Börjesson wrote: >> How many times does this have to be repeated? Severity levels are NOT >> determined by how much a user wants the app to work. They're just not, >> deal with it. > > I have never said it is, either. > I said it think it should be determined by how severe the user thinks > it is(if devs then cares about it is another matter). And you've already been told it shouldn't, and this has been explained to you. <snip waffle> Junk.

May 3, 2009

Re: Giving up for now

by Massimo Del Fedele

Roderick Colenbrander ha scritto: >> > > Have you also tried to use the GDI AlphaBlend function? This is the > one which should be used I think and we back it by XRender .. > > Roderick > > Sorry for the OT : apropos AlphaBlend and RGBA bitmaps... what happens with BitBlt on a destination DIB which has alpha channel ? it gets overwritten or the dest alpha channel is simply ignored ? I mean BitBlt(dstBmp......., SRC_COPY) what happens to dstBmp alpha ? and BitBlt(dstBmp......., SRC_AND) ??? Max

May 3, 2009

Re: Severity levels

by Nicklas Börjesson

>How many times does this have to be repeated? Severity levels are NOT >determined by how much a user wants the app to work. They're just not, >deal with it. I have never said it is, either. I said it think it should be determined by how severe the user thinks it is(if devs then cares about it is another matter). You seem to be convinced that all users are morons hyping their own stuff. >>>If a set of devs decide to work on getting a particular app working >>>that's up to them, and we've already been over this too. >> Obviously. I can't remember opposing that? >Who said you had? Why writing that we've had already been over it, then?!?? .....etc.... "you can't see the picture" .....etc.... "Not to you, no. Only what you think is right." .....etc.... Huh? This doesn't lead anywhere, you constantly misread me and I don't seem to understand what you are getting at. For some reason, I seem to annoy the hell out if you. I really don't get it, it is not my intention. Do I have some kind of attitude I need to be aware of? I am not a native English speaker. Anyway, it has been obvious from the start that you and I can't communicate. Therefore, I am backing out(hands in air) of this discussion before...uh.. after it has gotten out of hand. //Nicklas

May 3, 2009

Re: Giving up for now

by Roderick Colenbrander

On Sun, May 3, 2009 at 6:28 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > On Sat, May 2, 2009 at 11:18 PM, Joel Holdsworth > <joel(a)airwebreathe.org.uk> wrote: >> On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >>> On Sat, May 2, 2009 at 8:57 PM, Joel Holdsworth >>> <joel(a)airwebreathe.org.uk> wrote: >>> > On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: >>> >> On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth >>> >> <joel(a)airwebreathe.org.uk> wrote: >>> >> > Hi All, >>> >> > >>> >> > I've hit a bit of a wall with alpha blended icons. CreateIcon is working >>> >> > fine for icon creation, but ExtractIcon and LoadIconFromResource etc. >>> >> > are all proving more of a problem. All of these use various GDI DIB >>> >> > functions to coerce the icon bitmap to the correct colour depth and >>> >> > size. The problem is that preserving the alpha channel through these DIB >>> >> > functions seems to be impossible because they go via X11, so until the >>> >> > dib engine is merged (after hell freezes over) I'm not sure I can go >>> >> > much further. >>> >> > >>> >> > Joel >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >>> >> If you say X11 might be problematic note that more and more display >>> >> drivers are offering visuals with alpha, so 32-bit ones instead of >>> >> 24-bit. You could force the selection of such a visual in winex11.drv >>> >> for testing. >>> >> >>> >> Roderick >>> > >>> > Is that right? I simply assumed it would screw it up. If the problem can >>> > be solved with fixes to user32 or gdi32, then I can probably find the >>> > solution. If it involves work on winex11, then I'm not really the right >>> > guy for the job. >>> > >>> > >>> > >>> >>> Why again did you need this specific alphablend method? The icon can't >>> be converted to use some basic color keying for transparency or so? >> >> The reason is that the outlines will look aliased, and there will be no >> drop-shadows - without alpha the Tango icons won't look better than the >> current set. Also, I figured that icon rendering should be fixed for the >> sake of wine as a whole - which I think it should. It seems like a good >> little task for a wine beginner, and indeed I've made a lot of progress >> - I'm just a bit stuck. >> >> The culprit is a transfer through StretchDIBits in user32 which strips >> the alpha channel. I can't see a way round it - using StretchBlt doesn't >> help, and neither does GdiTransparentBlt. >> >> Another insentive: I suspect fixing this would also fix bug #201 which >> is now over 8 years old! >> >> >> > > I just looked a little more into it. As you mentioned StretchDIBits in > user32 removes the alpha channel. According to this post at MSDN > (http://msdn.microsoft.com/en-us/library/dd145023(VS.85).aspx) the > function got extended in Vista to include PNG support because PNG is > used for most icons in Vista. It might be useful to check that out. > The page mentions it was meant for printers but most likely they also > use this for icon rendering. I think it can be used in cooperation > with XRender (there are various xrender examples for dealing with > alpha). > > Roderick > Have you also tried to use the GDI AlphaBlend function? This is the one which should be used I think and we back it by XRender .. Roderick

May 3, 2009

Re: Office 2007 MSI Crash - Null dereference @ MsiViewExecute

by Mike Kaplinskiy

On Thu, Apr 30, 2009 at 1:08 PM, James Hawkins <truiken(a)gmail.com> wrote: > On Thu, Apr 30, 2009 at 4:03 AM, Austin English <austinenglish(a)gmail.com> wrote: >> On Tue, Apr 28, 2009 at 9:27 PM, Mike Kaplinskiy >> <mike.kaplinskiy(a)gmail.com> wrote: >>> I was looking at the trace of the crash from bug 17600, and it looks like >>> a custom action is calling MsiViewExecute with a null hRec. >>> >>> I (sadly) don't know much about the wine MSI architecture, but the >>> msiobj_lock on line 484 should fail since rec will never be fetched >>> (null). I think the intention was to make it query->hdr (as it is >>> released later). >> >> A testcase for it would show if you're right or wrong ;-). >> > > Not really. If you grep through the msi tests, you'll see that we > call MsiViewExecute with NULL hRec all over the place. That doesn't > mean there isn't a bug, just saying. > > -- > James Hawkins > So I got a little time to look into this, and was completely blown away. Apparently doing TRACE("dereferencing 0?=%p\n", (void *) &(((MSIRECORD *) NULL)->hdr)); works, since nothing ever gets dereferenced. I will post a patch for this small nit. On a slightly different note, I have traced the problem in office 2007 to the patch by James, and in particular to INSERT_execute. The row index gets set to 0 if the primary key is null (which is what office install is doing), but if the insert is temporary TABLE_insert assumes that row >= tv->table->row_count, and subtracts from the row index, putting us in the negatives (or high positives due to uint). I have a patch for this, but I don't know how to make a testcase (all I know is office installs), so would anyone mind pointing me to somewhere that explains msi temporary inserts? And should I post the patch up on wine-patches to get it critiqued? (sorry, first time) Mike.

May 3, 2009

Re: Severity levels

by Ken Sharp

Nicklas Börjesson wrote: >> No it isn't. It's an indication on how many people think they're more >> important than anyone else filing a bug. > > I think that you are wrong. Granted, some people do, they are called morons. > But most people aren't morons. They are people, and to them, the issue really > is critical. At least they think that. Give people the benefit of the doubt here. How many times does this have to be repeated? Severity levels are NOT determined by how much a user wants the app to work. They're just not, deal with it. > >> It doesn't matter what the users think, we've been over this, it would >> be up to MS coders. >> They would put a high priority on it because Adobe it a major player, >> and I'm sure MS makes a lot of money out of them one way or another. >> This is a FOSS project and has no bearing on severity levels. > > So Photoshop has not been the least prioritized? What are you talking about? A lot of people use Photoshop, that's why it has been given more attention. This is FOSS software, the more popular an application is, the more people will be involved in getting it to work. Photoshop is very popular. "Acme Inc. Card Counter" is not. Photoshop has been prioritised because it is so popular, it is also affected by a LOT of bugs. This adds up to 1+1=2 and nothing more. Photoshop bugs are prioritised in exactly the same way all the other bugs are. > I don't think you paint the entire picture. I don't think you can see the picture. > >> If a set of devs decide to work on getting a particular app working >> that's up to them, and we've already been over this too. > > Obviously. I can't remember opposing that? Who said you had? > >> Bares no relevance whatsoever to severity levels in Bugzilla. > Nothing does, does it? Not to you, no. Only what you think is right. > > //Nicklas >

May 3, 2009

RE: Severity levels

by Nicklas Börjesson

>No it isn't. It's an indication on how many people think they're more >important than anyone else filing a bug. I think that you are wrong. Granted, some people do, they are called morons. But most people aren't morons. They are people, and to them, the issue really is critical. At least they think that. Give people the benefit of the doubt here. >It doesn't matter what the users think, we've been over this, it would >be up to MS coders. >They would put a high priority on it because Adobe it a major player, >and I'm sure MS makes a lot of money out of them one way or another. >This is a FOSS project and has no bearing on severity levels. So Photoshop has not been the least prioritized? I don't think you paint the entire picture. >If a set of devs decide to work on getting a particular app working >that's up to them, and we've already been over this too. Obviously. I can't remember opposing that? >Bares no relevance whatsoever to severity levels in Bugzilla. Nothing does, does it? //Nicklas

May 3, 2009

Re: Severity levels

by Ken Sharp

IneedAname wrote: > On Sun, 03 May 2009 18:10:03 +0100 > Ken Sharp <kennybobs(a)o2.co.uk> wrote: > >> That would be the "Show Apps affected by this bug" link then. >> http://appdb.winehq.org/viewbugs.php?bug_id=16281 > > Thanks I missed that so how but my first point still stands. > Not really. 16281 certainly isn't a major loss of functionality, no matter how many bugs are attached to it.

May 3, 2009

RE: Severity levels

by Nicklas Börjesson

>So you suggest making the severity ratings meaningless to anyone but >... well, you don't actually mention anyone knowing what they *really* >mean, but I assume an exclusive clique of developers or bugzilla >admins? Users have different opinions on what level of bug they >encounter depending on what *task* they're trying to perform, which is >not particularly useful to developers who need strict reproducability. No, I mean that the actual meaning of the words "low", "medium", "high" and "Critical" will suffice. I think most people have a fair understanding what "medium" and "critical" means. This is not meaningless at all, to trying to clarify these levels is quite pointless though. Yes, some people tend to exaggerate their issues, but that's just the way it is. And to my experience, they are few. Most actually don't exaggerate as much. To them, the situation IS critical, bordering on panic. Rather, thinking that their users are exaggerating is a way for developers to not let reality come to close. Hell, I do it myself right now. :-) I don't see how the reproducibility connects to the severity level? Regarding the priority flag..i was referring to it's visibility, not its state. >There already is a separate category flag. It's called "severity" and >it indicates roughly the amount of *functionality* lost due to the >bug. "Priority" does not indicate the severity of a bug; a bug may >have low priority due to limitations outside of Wine (such as some >blocker bugs for copy-protection systems which can't be supported in >Wine). My point is that there should be no need for that flag. Let the users have it as input, and let the developers use component+priority. >You're not going to like this, but users don't matter quite *that* >much on bugzilla. The bug tracker is a developer's tool, and although >users are essential to the process (submitting bugs and new >information on request), it should be designed as a developer's tool. >A user's impression of their problem is irrelevant to the hard data >they can provide about lost or missing functionality. You are right. I don't like it. Especially because the bug tracker is the entire projects tool, not only the developers. I this matter can only compare with my own professional(commercial) experience and there, the ones submitting bugs has a *lot* to say, since they won't submit bugs unless they are critical if we don't present them with a smooth interface. Hmm..only critical bugs..now where have i heard about that..? :-) //Nicklas

May 3, 2009

Re: Severity levels

by Austin English

2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >> You'd be surprised... > We'll I've looked around at "invalids", but to me it seems that people in general(with a few exceptions of course), tries quite hard until they file a bug report. > At least way harder than they do in other FOSS projects I have been involved in, so I can't really say that I would think you've got a problem. > At least not yet. Despite the support forum only have one list. More stuff on the wiki would help too. Why should there be multiple support forums? The wiki has _a lot_ of info, most of the time when bugs are closed invalid, wiki links are given to fix the problem. Again, wine _is_ an open source project. If the wiki isn't good enough, add something. > What I am talking about the fact that the ordinary users priorities are very important. > Currently they are either: > 1.Completely disregarded or > 2. If they follow the instruction(where "commons sense" is not mentioned), they're forced to adhere to severity levels that distort or hide their opinion of the problem. And for each user reporting there are dozens that are not. Bad will. How do you mean their priorities are important? It's an uncomfortable truth, but users priorities aren't important, like has been said dozens of times. Sure, we care about user's bugs, and want to fix them. But every user also thinks *their* app is the most important application to fix. I regularly change around 3-5 bugs _a day_ that are marked critical, because their favorite app XYZ doesn't run. A good portion of that time, the bug is invalid, because they forgot a runtime, e.g., the application didn't bundle msvcrt80 or the like. Wine can't stop development on _everything_ just to get one user's application running. Making user's arbitrary priorities the most important would be doing this. > It just feels like the entire project should become a bit more user-centric. > Now I am not just talking about shinier graphics but about attitude. > Maybe soften up a bit ask oneself, "WHY did this person ask this stupid question?", "WHY did he do this EVEN though it says do this?" or "How would I feel if someone said this to me?". No disagreement there. Most developers do have a friendly attitude towards users. If they don't, e-mail them in private, with a copy of what they said and ask them to be more civil. I'd encourage you to subscribe to wine-bugs for a while. Look how much mail/bugs we go through, and you'll quickly see why time to hold every users hand and fix _their_ most important bug is impossible. -- -Austin

May 3, 2009

Re: Severity levels

by Ken Sharp

Nicklas Börjesson wrote: >> To every Wine user, their application not working is critical. This is >> clear by all the bugs that are logged incorrectly every day, because >> nobody bothered reading the FAQ. > > Yep, but that's more an indication on how much work remains to be done on wine than it is an incorrect severity level. No it isn't. It's an indication on how many people think they're more important than anyone else filing a bug. > If Photoshop(the eternal example) should stop working on windows due to a regression, I am sure the users would consider it critical when they report it to Microsoft. It doesn't matter what the users think, we've been over this, it would be up to MS coders. They would put a high priority on it because Adobe it a major player, and I'm sure MS makes a lot of money out of them one way or another. This is a FOSS project and has no bearing on severity levels. If a set of devs decide to work on getting a particular app working that's up to them, and we've already been over this too. > > But as the wine project progresses, severity levels will hopefully drop so that there will be more nuances. As Wine progress, the higher severities will be less and less. Higher sev levels will stand out a lot more. That's what they're for. > > I just think there is something severely when registering a bug that results in unworkable applications is considered a "normal" or even "minor" bug. > To me, that's sending the wrong signals about the ambition of the project. Nobody else seems to have this problem. > Unless the "not yet suitable for general use" from the faq is everywhere with blinking warning signs. Bares no relevance whatsoever to severity levels in Bugzilla. > > //Nicklas > > > Note to self: Reply to ALL.

May 3, 2009

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

by Rein Klazes

On Fri, 01 May 2009 22:15:16 +0200, you wrote: >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. Indeed you were right. Setting the WS_[HV]SCROLL with a SetWindowLong does not create the scrollbar info, which proves unambiguously that my idea was false. I guess to fix the windows style test failures some SetScrollSomething will have to be done in the CreateWindow functions. I'll postpone that for another patch and send now the patch which only fixes the separate scollinfo structures, which is enough for the bugzilla bug. Rein.

May 3, 2009

Re: Severity levels

by Ken Sharp

IneedAname wrote: > On Sat, 2 May 2009 16:52:06 +0200 > Nicklas Börjesson <Nicklas.Borjesson(a)ws.se> wrote: > >> 3. Major "Major loss of functionality for a wide range of applications >> >> - Isn't this just all bugs that has more than $arbitrary_number of applications linked to them? An aggregate, rather than a level? > > In that case #16281 would be major not minor, That is if all the applications that has that bug link to it. > > I think you can not find out how many applications link a bug. As that has not be coded. > To find out that information you would have to scan the application data base or change the way the data base holds this data. > I think you want to read bug #16284. > > That would be the "Show Apps affected by this bug" link then. http://appdb.winehq.org/viewbugs.php?bug_id=16281

May 3, 2009

RE: Severity levels

by Nicklas Börjesson

>To every Wine user, their application not working is critical. This is >clear by all the bugs that are logged incorrectly every day, because >nobody bothered reading the FAQ. Yep, but that's more an indication on how much work remains to be done on wine than it is an incorrect severity level. If Photoshop(the eternal example) should stop working on windows due to a regression, I am sure the users would consider it critical when they report it to Microsoft. But as the wine project progresses, severity levels will hopefully drop so that there will be more nuances. I just think there is something severely when registering a bug that results in unworkable applications is considered a "normal" or even "minor" bug. To me, that's sending the wrong signals about the ambition of the project. Unless the "not yet suitable for general use" from the faq is everywhere with blinking warning signs. //Nicklas

May 3, 2009

Re: wine-devel Digest, Vol 46, Issue 10

by chris ahrendt

wine-devel-request(a)winehq.org wrote: > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-devel > > > ------------------------------------------------------------------------ > > Subject: > Re: RFC on Base Wine Config > From: > Kai Blin <kai.blin(a)gmail.com> > Date: > Sun, 3 May 2009 09:04:13 +0200 > To: > wine-devel(a)winehq.org > > To: > wine-devel(a)winehq.org > > > On Sunday 03 May 2009 07:07:35 Ben Klein wrote: > >> 2009/5/3 chris ahrendt <celticht32(a)yahoo.com>: >> > > Replying to Ben's email as I didn't get Chris' email Ben replied to. > I would also like to note that I don't appreciate the tone both of these > emails are taking in the end. Please try to be civil. > > That being said, let me get to the technical part. > > >>> I guess I am not being completely clear somewhat.... >>> If I am in windows and go into explorer... >>> >> We've been through this before. Wine is not Windows. In Wine, the >> drive has to be mapped in dosdevices. >> >>> go to a network drive. I do >>> not nescisarily have to map that drive in order to run an application >>> (so long as the DLLS it needs, if any, are not just on that drive). I >>> can click the application >>> and it runs. I realise this may be a fundamental difference between unix >>> and windows but still they should theoretically run the same. >>> > > The important part here is that your local drives are local drives. Don't > confuse the Wine drive mappings with network drive mappings in Windows. Think > about a Wine drive mapping like plugging a new hdd into your box. > > >> But you're NOT running the test from a network drive, are you? And >> even if you were, you'd need some way to inform Wine that it's there, >> which would be to map it to a drive. Does Wine even support >> Windows-style shares? >> > > Nope. We could, but then you'd have to create a Samba share to allow us to use > the directory. I'm pretty sure a wine drive mapping is easier and faster. > > >>> Also from >>> a command line I can do (I think if I am remembering correctly (been >>> doing to much z work lately) ) //server/directory/app.exe and it will >>> retrieve and run the app... (I think) >>> > > That's a bit besides the point, as this is still a valid UNC path. Now imagine > I've got a USB hdd with my app on it, and that's usually connected at U:, > with my app being at U:\test\app.exe. Now the logic in Windows mapping my USB > drive to U: is just what the wine dosdevice mapping is like. If I now tell > windows to remove the USB device, my desktop link to U:\test\app.exe is not > going to work anymore. > > >> This message appears in your bug report: >> >>> Warning: could not find DOS drive for current working directory >>> '/home/cahrendt/wine-git/dlls/inetmib1/tests', starting in the Windows >>> directory. >>> > > Here my analogy would be a bit stretched, as in that you'd still manage to be > on the USB drive while it's already been disconnected. But basically you're > trying to run a program that's on a drive not connected to your wine "box". > > Cheers, > Kai > > > Thanks Kai, This is the kind of dialog I was looking for in the RFC. This makes sense. In a way with you are in a seperate 'region' and do not have access to that regions resources unless you map it. Even though wine is not a emulator it is essentially a VM running in userspace on the box that you need to allocate some resources to. (not so much like solaris 10 or zVM's where you can set up resources for everything). Ok clear now. Chris

May 3, 2009

Re: Giving up for now

by Roderick Colenbrander

On Sat, May 2, 2009 at 11:18 PM, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >> On Sat, May 2, 2009 at 8:57 PM, Joel Holdsworth >> <joel(a)airwebreathe.org.uk> wrote: >> > On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: >> >> On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth >> >> <joel(a)airwebreathe.org.uk> wrote: >> >> > Hi All, >> >> > >> >> > I've hit a bit of a wall with alpha blended icons. CreateIcon is working >> >> > fine for icon creation, but ExtractIcon and LoadIconFromResource etc. >> >> > are all proving more of a problem. All of these use various GDI DIB >> >> > functions to coerce the icon bitmap to the correct colour depth and >> >> > size. The problem is that preserving the alpha channel through these DIB >> >> > functions seems to be impossible because they go via X11, so until the >> >> > dib engine is merged (after hell freezes over) I'm not sure I can go >> >> > much further. >> >> > >> >> > Joel >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> >> If you say X11 might be problematic note that more and more display >> >> drivers are offering visuals with alpha, so 32-bit ones instead of >> >> 24-bit. You could force the selection of such a visual in winex11.drv >> >> for testing. >> >> >> >> Roderick >> > >> > Is that right? I simply assumed it would screw it up. If the problem can >> > be solved with fixes to user32 or gdi32, then I can probably find the >> > solution. If it involves work on winex11, then I'm not really the right >> > guy for the job. >> > >> > >> > >> >> Why again did you need this specific alphablend method? The icon can't >> be converted to use some basic color keying for transparency or so? > > The reason is that the outlines will look aliased, and there will be no > drop-shadows - without alpha the Tango icons won't look better than the > current set. Also, I figured that icon rendering should be fixed for the > sake of wine as a whole - which I think it should. It seems like a good > little task for a wine beginner, and indeed I've made a lot of progress > - I'm just a bit stuck. > > The culprit is a transfer through StretchDIBits in user32 which strips > the alpha channel. I can't see a way round it - using StretchBlt doesn't > help, and neither does GdiTransparentBlt. > > Another insentive: I suspect fixing this would also fix bug #201 which > is now over 8 years old! > > > I just looked a little more into it. As you mentioned StretchDIBits in user32 removes the alpha channel. According to this post at MSDN (http://msdn.microsoft.com/en-us/library/dd145023(VS.85).aspx) the function got extended in Vista to include PNG support because PNG is used for most icons in Vista. It might be useful to check that out. The page mentions it was meant for printers but most likely they also use this for icon rendering. I think it can be used in cooperation with XRender (there are various xrender examples for dealing with alpha). Roderick

May 3, 2009

Re: Severity levels

by Ken Sharp

Nicklas Börjesson wrote: > I think that the users should have quite a say with regards to how important a bug is, because for every user > putting in the (considerable for a user) effort of reporting a bug, there are dozens that don't say anything at all. To every Wine user, their application not working is critical. This is clear by all the bugs that are logged incorrectly every day, because nobody bothered reading the FAQ.

May 3, 2009

Re: Limit of todo_wine ?

by Massimo Del Fedele

Vincent Povirk ha scritto: > This is by design. Each call to ok() is an individual test, > independent of the others, and todo_wine marks them all as todo. > > If you have the same code running multiple tests, you can mark some of > them as todo by putting a todo flag in your data. > > If you really want multiple checks to be dependent, you'll need to > reduce them to one ok() call. > > Vincent Povirk > > > Yep, that what I'm doing now.... but the code is quite less clean than before. Thank you for answer Max

May 3, 2009

Re: Limit of todo_wine ?

by Vincent Povirk

This is by design. Each call to ok() is an individual test, independent of the others, and todo_wine marks them all as todo. If you have the same code running multiple tests, you can mark some of them as todo by putting a todo flag in your data. If you really want multiple checks to be dependent, you'll need to reduce them to one ok() call. Vincent Povirk

May 3, 2009

Limit of todo_wine ?

by Massimo Del Fedele

Today writing a testcase I found a "problem" on todo_wine construct. In short : void first_test_part() { ok(test1(), "failed\n"); } void second_test_part() { ok(test2(), "failed\n"); } todo_wine { first_test_part(); second_test_part(); } this "fails" (i.e. is marked as passing inside todo_wine block) if first_test_part() passes, which is not what wished; in this case the test should be considered passing if BOTH first and second part passes, and failed otherwise. The problem arose on bitmap creation test (gdiplus) on which the testcase should check for creation success AND bitmap internal consiscency. My example is short, but in my case there's a single function used to test many kind of bitmaps; that's impossible to do with todo_wine actual construct. It could be obviously separated into many functions, each enclosed on its own todo_wine, but this would vanify the "single test function for many bitmaps types" way. Max

May 3, 2009

Re: Severity levels

by Ben Klein

2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > >>I disagree. When first introduced to them, I found the severity levels >>to be suitably vague to make me read the definitions. Once I read >>them, it was clear to me what each level means. > > Suitably? Do you mean that the severity levels are the way they are to make people read their definitions? :-) > > Jokes aside, that's exactly what I don't want. > I want them to be even more vague(Low, Medium, High and Critical) and without any definitions except for the highest level. > This way, one will elicit more how the user perceives the overall impact of the bug, without having to shoehorn them into some level that only partly matches their impression. Done with the help of the users indisputable "common sense", of course. So you suggest making the severity ratings meaningless to anyone but ... well, you don't actually mention anyone knowing what they *really* mean, but I assume an exclusive clique of developers or bugzilla admins? Users have different opinions on what level of bug they encounter depending on what *task* they're trying to perform, which is not particularly useful to developers who need strict reproducability. > Also, the priority flag should not be visible to the user by default, it should be a strangely named setting somewhere in the user preferences. It already is a strangely named setting, but the user preferences is far from the right place for it. It still has to be on a per-bug level, and although it may not be the most useful option on bugs it is still used by developers in-the-know, so maybe an additional message that says "Don't change the priority setting unless you know exactly what you're doing"? It's academic anyway, as the priority can be appropriately adjusted later. >>But bear in mind the severity levels are there >>to help the developers categorise the bugs, and they are not there to >>provide feedback to the average non-coding user. > For categorisation, there could be a separate category flag if the "component" categorisation + priority wouldn't suffice. There already is a separate category flag. It's called "severity" and it indicates roughly the amount of *functionality* lost due to the bug. "Priority" does not indicate the severity of a bug; a bug may have low priority due to limitations outside of Wine (such as some blocker bugs for copy-protection systems which can't be supported in Wine). > Whatever. There are many ways to do it. But currently, the users' impression of the problem get lost and/or skewed. You're not going to like this, but users don't matter quite *that* much on bugzilla. The bug tracker is a developer's tool, and although users are essential to the process (submitting bugs and new information on request), it should be designed as a developer's tool. A user's impression of their problem is irrelevant to the hard data they can provide about lost or missing functionality.

May 3, 2009

Re: Giving up for now

by Roderick Colenbrander

On Sun, May 3, 2009 at 2:44 AM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/5/3 Joel Holdsworth <joel(a)airwebreathe.org.uk>: >> On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >>> Why again did you need this specific alphablend method? The icon can't >>> be converted to use some basic color keying for transparency or so? >> >> The reason is that the outlines will look aliased, and there will be no >> drop-shadows - without alpha the Tango icons won't look better than the >> current set. Also, I figured that icon rendering should be fixed for the >> sake of wine as a whole - which I think it should. It seems like a good >> little task for a wine beginner, and indeed I've made a lot of progress >> - I'm just a bit stuck. >> >> The culprit is a transfer through StretchDIBits in user32 which strips >> the alpha channel. I can't see a way round it - using StretchBlt doesn't >> help, and neither does GdiTransparentBlt. >> >> Another insentive: I suspect fixing this would also fix bug #201 which >> is now over 8 years old! > > What format are your Tango icons in? Are you converting them to .ICO > files as you go, or leaving them in PNG/some other known alpha channel > supporting format? > > > We do support some alpha support using XRender, can't you use this too? I think that's the general method for using alpha at the moment on X. Roderick

May 3, 2009

RE: Severity levels

by Nicklas Börjesson

>I disagree. When first introduced to them, I found the severity levels >to be suitably vague to make me read the definitions. Once I read >them, it was clear to me what each level means. Suitably? Do you mean that the severity levels are the way they are to make people read their definitions? :-) Jokes aside, that's exactly what I don't want. I want them to be even more vague(Low, Medium, High and Critical) and without any definitions except for the highest level. This way, one will elicit more how the user perceives the overall impact of the bug, without having to shoehorn them into some level that only partly matches their impression. Done with the help of the users indisputable "common sense", of course. Also, the priority flag should not be visible to the user by default, it should be a strangely named setting somewhere in the user preferences. >But bear in mind the severity levels are there >to help the developers categorise the bugs, and they are not there to >provide feedback to the average non-coding user. For categorisation, there could be a separate category flag if the "component" categorisation + priority wouldn't suffice. Whatever. There are many ways to do it. But currently, the users' impression of the problem get lost and/or skewed. //Nicklas

May 3, 2009

Re: [shell32] stub for ExtractVersionResource16W

by Reece Dunn

2009/5/3 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > "Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > >>> Also you might be interested that according to >>> >>> http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shell32/h >>> istory/names351.htm ExtractVersionResource16W is discontinued starting >>> from >>> Windows Vista. >> >> What does the second point means for wine? > > That means that if Microsoft has dropped that API from Vista, > all apps that use it no more will function on Vista and newer > Windows generation. Therefore Wine is free to drop it as well. Not really. Wine is designed to run Windows programs on Linux, Mac, BSD and OpenSolaris platforms. That means that if an application is using this API, then Wine should support it. If this is Wine making the call internally (and no applications explicitly depend on it), then the API can be dropped from Wine as well. - Reece

May 3, 2009

Re: RFC on Base Wine Config

by Stefan Dösinger

Am Sonntag, 3. Mai 2009 13:42:24 schrieb Paul TBBle Hampson: > The point made as I recall it in the earlier thread is that this is a > false sense of security, and that apps can already get outside the drive > mappings for filesystem access. > > I don't know how, but that was the point that was made. Linux syscalls. A Windows app can happily call int 0x80 to do whatever a Linux app running with the same permissions can do. It requires the app to be aware of Wine though.

May 3, 2009

Re: RFC on Base Wine Config

by Paul TBBle Hampson

On Sun, May 03, 2009 at 08:54:32PM +1000, Ben Klein wrote: > 2009/5/3 Paul TBBle Hampson <Paul.Hampson(a)pobox.com>: >> On Sun, May 03, 2009 at 03:07:35PM +1000, Ben Klein wrote: >>> It's NOT a networked drive, is it? Drive mappings are the only way to >>> tell Wine and apps running in Wine where your files are in your >>> host-system (Unix-style) filesystem. >> The discussion on wine-devel in April related to bug 15883 suggested the >> implementation of \\?\unix\ which would in turn allow programs access to >> things that aren't mapped in the DosDevices list, unless specifically >> disallowed (which wasn't discussed at the time) >> A quick look at [1] suggests that \\?\unix\etc/hostname would seem to be >> a reasonable thing to expect to work under Wine. > But that requires either > 1) the app to be aware of \\?\unix, or This would be rather badly broken. The point of \\?\ is that apps (and in fact the Win32 API) doesn't parse such paths, but passes them on to the filesystem. > 2) Wine to map \\?\unix/foo/bar when no drive mapping to /foo/bar exists. The _point_ is that if Wine sees a \\?\unix/foo/bar path, it operates upon the file at /foo/bar, irrespective of the drive mappings. > #2 would also require some way to be configured to allow the > equivalent of removing the default Z: drive mapping for people who > want it. However, it would not provide any additional functionality > and could easily be considered a waste of time. Of course, that's not > up to me ;) The point of \\?\unix is not to add functionality, it's to allow removal of current functionality, specifically the magic recognition of "/x/y" as a unix path instead of "X:/x/y" with X as the drive of the current working directory, in order to fix bug 15883. >>> Note that it would be a breach of security to allow some method to >>> access / without a direct mapping in dosdevices. >> How so? I'm fairly sure this suggestion was dismissed in the >> above-mentioned email discussions as well. > AFAIK, the main reason people remove the Z: mapping is a security > concern. It's not an issue for me, but some people like to restrict > the files that win32 apps can access to a subdirectory in $HOME. If > there's some workaround to access files outside the drive mapping > (assuming pure win32 of course :D ), then unless it can be disabled by > the user, it's a security breach. The point made as I recall it in the earlier thread is that this is a false sense of security, and that apps can already get outside the drive mappings for filesystem access. I don't know how, but that was the point that was made. Off the top of my head, there's Win32 APIs that let you enumerate and map physical disk devices to DOS drive letters. So you could just readd Z:\ in your app if you wanted. Frankly I would like to break that illusion of security by providing \\?\unix, if I find the time. (The hard part is identifying all the parts of Wine that use the '/' recognition to function) -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

May 3, 2009

Re: Severity levels

by Ben Klein

2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > Ok..you seem to have misunderstood the tone in my mail. > >>Without common sense, all bug reports would be "Enhancement" requests, >>or "Critical", depending on how arrogant the reporter is. Common sense >>must *always* be applied. > > I should be needed to be applied only to the least possible amount. One should never have to think for no reason. > The more "common sense" that have to be applied to make something work, the less something works by itself. > Of course, you can't completely do away with common sense. I said "without common sense" to point out the problems. > And, well, some have less common sense. Or a different kind. Or are just tired, stressed out or something else. > So, the less common sense needed, the better, IMO. My other point is that reporters are like to become less technical. > >> Oh, and use "Reply to all" so you stop just hitting Austin with responses! > > Huh? The mailing list is cc:d, Isn't that enough? I mean, it looks on you mail you mailed me and cc:d? > Doesn't the mailing list propagate messages if it is only cc:d? > Have I misunderstood something? In that case I am sorry. My apologies. I received Austin's responses before receiving your original emails. >>Rosanne is an AppDB admin. What contribution have you made to Wine? >>Out of you and her, I don't think her credibility can be called in to >>question. And before you ask, I'm also an AppDB admin, I package the >>Debian packages for WineHQ, and have had a patch committed to Wine. >>I'll even send you the git revision code if you can't find it! :D > >>Note that like Rosanne, even when I was a newbie submitting bug >>reports, I understood the severity levels because I read the >>descriptions. The descriptions are fine as is, with the possible >>exception of "Blocker" (people submit "Blocker" bugs for "Normal" >>issues because it blocks the thing that they're doing). > > It's seems you missed the ":-)". I put in the end of the sentence on credibility. > It was a joke and she seems to have took it that way, since she joked back. > With regards to the severity levels, to me, none of them means what one would think they do intuitively. I disagree. When first introduced to them, I found the severity levels to be suitably vague to make me read the definitions. Once I read them, it was clear to me what each level means. Either way, severity levels can be changed, and often are due to user responses on the bugs. But bear in mind the severity levels are there to help the developers categorise the bugs, and they are not there to provide feedback to the average non-coding user.

May 3, 2009