June 2006 - Wine-Devel - list.winehq.org

Re: How are we doing?

by KGJ

Hi, Tony Lambregts wrote: > In the interm I believe the AppDB has helped a lot. I think that the > work that we have put into it has paid off fairly well to a point. So > far we have added: > > - Applications Maintantainers that can modify application entries on > an App by App basis. > > - Notification emails so that people (Administrators, Maintainers and > Monitors) kept up to date on changes to applications. > > - Bug links to track bugs affecting an application. > > - Test results to track how well an application runs on a Wine > version. and help spot regressions > > - Lots of small improvements. > > Lots of thanks to Chris Morgan and Johnathan Ernst and everyone else > that submited patches to get it to its current state. > > However there are a number of things that are needed still. > > - We need a general search page. > > - It would be nice to have the ability for people to have classes of > rights so that they can add/change/delete certain fields IE: > "Application Description" without having to become a maintainer or > administrator. > > There is a todo list here as well. http://wiki.winehq.org/AppdbInfo > > If anyone has experience with PHP or wants to gain some, there is a > real need for your help. > > > - A newsgroup set up that works the same as bugs so that anyone can > see the notifications generated by the AppDB. > > I asked Jeremy Newman for this before but I don't think that I > explained the need for it very well. (trying again) The AppDB is a great idea, but why is it so poorly integrated in the main page? The same question goes to the Bugtracker and the Wiki where the situation is even worse. On most web pages you have a navigation bar which remains the same as long as you are on the same page. But if you enter the AppDB or the Bugtracker you have the feeling that you are on an entirely new page which only have a link back to the main page and a similar design. If you enter one of the wiki pages the situation is even worse because it does not even have a link to the main page in the navigation bar. Is this a design decision or is it just the lack of time which prevents IMHO proper integration? Another thing I'd like to be changed is the "Paid Support" Link. Now it leads you direct to the codeweavers homepage. Well I'd not expect such a behaviour from a menu link. I would propose it to change it so that it opens a new window with the codeweavers page (ok I know that some people don't like that) or to make a new page under "Paid support" which contains the link to codeweavers (and perhaps others, if existent) I'm a PHP and C/C++ coder and I thought about working on the todo list but I don't like the idea of starting to work on something which won't satisfy me in the end. I don't even care what you think about me or my ideas. There are other projects which needs to be worked on, too. Don't get me wrong, wine is a super project and I use it daily to run my favorite instant messenger, but I think the climate is a bit cold for my taste. I thought a while whether to send the email here or to /dev/null, but I thought I should inform you what I don't like ;) Greetings KGJ

June 1, 2006

Re: How are we doing?

by Matt Finnicum

I will be working on riched20 for SoC - Initially I'll be working on some unimplemented messages and styles, and then I'll be working on some of the missing COM interfaces. Details are at http://wiki.winehq.org/MatthewFinnicum --Matt On 6/1/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Any status on what projects have been approved and > who is going to work on which project for this years SoC.

June 1, 2006

Re: How are we doing?

by Vijay Kiran Kamuju

Any status on what projects have been approved and who is going to work on which project for this years SoC. --- Vijay On 6/1/06, Kai Blin <blin(a)gmx.net> wrote: > * Detlef Riekenberg <wine.dev(a)web.de> [01/06/06, 01:15:28]: > > > Big Patches went into the tree: > > > > Juan Lang: crypt32: Implement CryptBinaryToStringA and > > CryptStringToBinaryA. > > > > When I saw the big Patch, i wanted to ask to split this in seperate > > Patches: > > 1x Header-Changes > > 2x Testcase (2 tested Functions -> 2 Patches) > > 2x Implementation ( 2 Functions) > > However, the Big patch was already in the Tree: > > http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html > > > > My only Idea is: "special Patch": SoC > > The only connection with SoC this patch has is that it's using the > base64 encoder/decoder I wrote for Summer of Code 2005. > > Besides, it took me unitl about november to finally get my SoC patches > with major functionality in, so SoC students certainly don't have any > bonus. > > Cheers, > Kai > > -- > Kai Blin, (blin at gmx dot net) > Quit worrying about your health. It'll go away. > -- Robert Orben > > >

June 1, 2006

Re: How are we doing?

by Kai Blin

* Detlef Riekenberg <wine.dev(a)web.de> [01/06/06, 01:15:28]: > Big Patches went into the tree: > > Juan Lang: crypt32: Implement CryptBinaryToStringA and > CryptStringToBinaryA. > > When I saw the big Patch, i wanted to ask to split this in seperate > Patches: > 1x Header-Changes > 2x Testcase (2 tested Functions -> 2 Patches) > 2x Implementation ( 2 Functions) > However, the Big patch was already in the Tree: > http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html > > My only Idea is: "special Patch": SoC The only connection with SoC this patch has is that it's using the base64 encoder/decoder I wrote for Summer of Code 2005. Besides, it took me unitl about november to finally get my SoC patches with major functionality in, so SoC students certainly don't have any bonus. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Quit worrying about your health. It'll go away. -- Robert Orben

June 1, 2006

Re: Text input box with scrollbar

by Detlef Riekenberg

Am Dienstag, den 30.05.2006, 11:06 -0300 schrieb Augusto Arcoverde da Rocha: > Hi all, > > Where I can find the inputbox drawing code? > > Some of these box appear with scrollbar when testing Action Request > System application under Wine, but not under MS Windows. Might be: dlls/user/edit.c (edit control), or dlls/riched20/* (rich edit control v2.0 and v3.0) (riched32 and msftedit are only wrapper for riched20) "DEVELOPERS-HINTS" is your friend :-) -- By By ... ... Detlef

June 1, 2006

Re: winspool/tests: [1/3] Tests for GetPrintProcessorDirectory

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > I want to be nice to make it easy for them to reuse our tests. > They got an SoC-Project for the Spooler, so the lifetime for this > test will be about half a Year up to the maximum of a Year. Nobody will ever fix it, since it silently handles both cases. > I can document in the wiki or in the Source the location for such Code, > that is not needed for Wine any longer but temporary still in Wine to > allow ReactOS to reuse our Code more effective. The tests are supposed to reflect the Windows behavior, not the Wine or Reactos behavior. Unless Windows returns ERROR_CALL_NOT_IMPLEMENTED here, it's not correct for Wine to do it, and that's what the test should express by using a todo_wine. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: winspool/tests: [1/3] Tests for GetPrintProcessorDirectory

by Detlef Riekenberg

Am Donnerstag, den 01.06.2006, 11:15 +0200 schrieb Alexandre Julliard: > Detlef Riekenberg <wine.dev(a)web.de> writes: > > > + SetLastError(0xdeadbeef); > > + res = GetPrintProcessorDirectoryA(NULL, NULL, 1, NULL, 0, &cbBuf); > > + if(!res && ( (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) || > > + (GetLastError() == 0xdeadbeef) )) { > > + trace("Not implemented yet\n"); > > + return; > > + } > > Unless there really is a Windows version that fails here, this test is > wrong. Things that are not implemented yet in Wine should be marked > with todo_wine, not ignored. Our current stub is just a FIXME, followed by "return 0". The missing "SetLastError()" is detected by "GetLastError() == 0xdeadbeef" I see no reason to run the rest of the tests for our stub or add a "SetLastError(ERROR_CALL_NOT_IMPLEMENTED)", that needs to be removed by the next Patch. ReactOS has SetLastError(ERROR_CALL_NOT_IMPLEMENTED) in every stub. I want to be nice to make it easy for them to reuse our tests. They got an SoC-Project for the Spooler, so the lifetime for this test will be about half a Year up to the maximum of a Year. I can document in the wiki or in the Source the location for such Code, that is not needed for Wine any longer but temporary still in Wine to allow ReactOS to reuse our Code more effective. -- By By ... ... Detlef

June 1, 2006

Re: wine problems on a 64bit system

by Alexandre Julliard

Mike Hearn <mike(a)plan99.net> writes: > As a hack you can change the code so every range of memory that is mapped > is mapped executable. Yes, I'm afraid we'll have to do that by default, there are too many broken binaries out there. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Alexandre Julliard

"Vincent Povirk" <madewokherd+d41d(a)gmail.com> writes: > So the HAL thing doesn't work for everyone, and this works for a lot > of people. When you see /media/cdrom, you can be sure it's a cd-rom > drive. So why not use it? Because HAL is supposed to work (assuming you have the proper libraries), and if it doesn't work this should be investigated and fixed. And once it's fixed, the drives created manually are going to interfere with it. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: How are we doing?

by Detlef Riekenberg

Am Donnerstag, den 01.06.2006, 11:45 +0200 schrieb Alexandre Julliard: > > During the Time, things changed and I get confused more and more times > > about "special Developers" and "other Developers", as well as "special > > Patches" and "other Patches". > > (It's also Possible, that i did not see the big differences before). > > There's no such thing as special developer vs. other developer, it's > more like a linear scale based on trust: Just a different wording for the same thing. :-) It's the Only way, how it can work. Not only here for accepting Patches, but everywhere for everything in the World. > the more I trust a developer > the easiest it is for him to get his patches committed. The only way > to earn trust points is by submitting consistently good patches. IMHO, modify trust points according the recent coding Area from a Developer can improve the quality of the committed Patches a little bit. To pick up my last Message, Stefan does a great Job for ddraw/dx. The trust for him is so high, that he was hired by Codeweavers. The quoted Patch was IMHO an unusual Coding-Area for him, because it was his first Patch for the regression tests. Another Example is the Testcase for GetPrinter by Dmitry Timoshkov (14. April). I'm working on winspool about a Year now and the Patch from Dmitry was the first one from him in the Area of winspool and winspool/tests for that time. The first view was enough for me to know, that this Test will produce a lot of failures and was never tested on any win9x-system, but is was already in the tree. I asked Markus for renaming sane.gs to winesane.ds and gphoto.gs to winegphoto.ds as well as wine-devel, Emmanuel Millard, Robert Reif and Ken Thomases to use dlls/winmm/winecoreaudio.drv as a starting point for dlls/wineaudio.drv. Both Patches where resend a day after my questions, but without any changes in this area (Over 100k of code). During my re-reading of the winecoreaudio-Patch yesterday, I missed the Part for winecfg/audio.c to extend sAudioDrivers with "coreaudio", but Robert has already send a message about this topic. > That doesn't mean you can't get stuff in if you aren't trusted, but it > means it will require extra scrutiny, which is why it's very important > at the beginning to send small patches that are easy to review. Once > you have earned enough trust you can get away with being a bit more > sloppy (but not too much, or you'll lose trust points again ;-) Another statement that we can use for the wine-dev-guide. Thanks -- By By ... ... Detlef

June 1, 2006