November 2008 - Wine-Devel - list.winehq.org

Governance of Wine with respect to the Software Freedom Conservancy
by Jeremy White Nov. 14, 2008

Nov. 14, 2008

Hi folks, As you may recall, several years ago, we decided to work with the Software Freedom Conservancy to ask them to manage aspects of Wine that merited the shield of a formal organization. They have been great, and a great improvement over our former process. I thought I'd send an email out for the record, expressing what they do for us, and how that is governed. First, there are essentially 2 major assets they manage for us. They manage all funds donated to Wine - the donate button goes into a bank account they manage. They also hold trademarks to the Wine logo that they filed on our behalf. For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, Dan Kegel, Alexandre, and myself are in contact with them. The goal is that all 3 of us agree on every decision, but 2 of the 3 of us must concur with any decision before it is effective. We three can appoint anyone else we choose to replace or augment the decision group. All decisions are CC'd to the WWN author (currently Zach Goldberg) for monitoring. The SFC will recognize a 'revolt' by the Wine project. That is, Dan, Alexandre and I can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor. Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has either been to pay for conference expenses directly (as in Reading, 2 years ago), or to help defray travel costs for Wine contributors to come to Wineconf (as happened this year). Cheers, Jeremy

1 0

Re: RFC: Wine Icons
by Branan Riley Nov. 14, 2008

Nov. 14, 2008

forgot CC on first send. On Fri, Nov 14, 2008 at 5:54 AM, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > Hi All, > > I notice that some of Wine's icons have been changed in recent releases. > In principle I think updating the icons is a great idea, but right now I > gotta say that icons in Wine are a real disaster. > > Take a look here: http://www.airwebreathe.org.uk/icons.png > > This is a screenshot of the shell folder select dialog. Out of those > icons My Documents looks the least broken - with it's wannabe 98/ME/2000 > styling. Desktop, "/", My Computer and Trash look like they've been > taken from large icons which have shrunk - badly, and with a broken > alpha channel. And the new golden Folder icons look completely out of > place - they bear no resemblance to anything else, they've been scaled > down poorly, they don't look like Windows icons, and they don't fit in > with the Gnome desktop (and I can't imagine they'd look good in KDE or > on Mac either). > > I'd really like for Wine to start using icons from the Tango project, or > similar. The purpose of Tango was to create a set of icons that are > clear to see, and look good on Windows, Gnome, KDE, and MacOS. Surely > that's exactly what we want? > > Note that ReactOS is using Tango, and it seems to be working out pretty > well for them! > > Any comments on that? > > Best Regards > Joel Holdsworth The problem with hardcoding Tango is that it won't necessarily match the user's desktop. On Linux and FreeBSD, I'd suggest finding a way to detect the current icon theme (perhaps determine which desktop environment is running, then read the config file for that desktop?) and use the freedesktop.org icon names and the XDG_DATA_DIRS variable to locate the icons. This wouldn't work on KDE3 (which doesn't use the freedesktop spec). In that case I would say fall back to the hicolor icons. On Mac, you should use the native mac icons, but that might not work to do Obj-C issues (I know nothing about mac programming, so maybe there's a way to get native icons without Obj-C?). This way, when theming is implemented, the icons and the theme will both match the user's desktop environment. It's more complicated than just implementing Tango, but visually it makes more sense. Branan

3 2

Re: imm32: implement ImmInstallIME(W/A)
by Juan Lang Nov. 14, 2008

Nov. 14, 2008

Hi Aric, minor nit: + if (rc == ERROR_SUCCESS) + return hkl; + else + { + FIXME("Unable to set IME registry values\n"); I think a WARN would be more approriate here. --Juan

1 0

Re: RFC: Wine Icons
by Branan Riley Nov. 14, 2008

Nov. 14, 2008

> I totally agree. Of course hardcoding visuals isn't nearly so cool as > doing them "properly", but right now that's what we've got - and these > hardcoded visuals are even being "upgraded", so if they're being > upgraded then wouldn't it be better to upgrade in the direction of some > kind of a standard? > > At least in the past the visuals sort-of looked consistent with Windows > 98. Now they don't look consistent with anything. Don't get me wrong: > the new icons I see aren't specially bad - it's just that they don't fit > with anything else. > > I wonder if we can fix this. > > Best Regards > Joel Holdsworth I don't have any problems with Tango in the short-term - Wine doesn't match my desktop anyway. I just don't want to see a huge amount of effort get put into it if a theming system is going to be put in place. But since the icons are being replaced anyway, I agree that using an already-existing icon set makes way more sense than creating all-new icons. Branan *sigh* the GMAIL web interface makes mailing lists such a pain. Sorry for getting this to you twice again, joel

1 0

re: Bugzilla - Add keyword and remove OS's
by James Mckenzie Nov. 14, 2008

Nov. 14, 2008

Sorry for the top post +1 for removing the Pre-X Mac OS's James McKenzie -----Original Message----- >From: Dan Kegel <dank(a)kegel.com> >Sent: Nov 14, 2008 8:35 AM >To: Wine Devel <wine-devel(a)winehq.org> >Subject: re: Bugzilla - Add keyword and remove OS's > >I think we should keep most of them, but classic Mac OS >(pre-X) can go, as we never worked there (not even Darwine), >and nobody cares about it anymore. I've deleted >Mac System 7, and will delete the rest of the classic >mac OS's if there is consensus. > >

1 0

Bugzilla - Add keyword and remove OS's
by Austin English Nov. 14, 2008

Nov. 14, 2008

Howdy, The OS list in bugzilla is a bit excessive. There are 16 OS's that I think we should remove, as no one is using them (HP-UX has one bug filed against it, but for all intents and purposes, it's not being used). Many of these aren't x86, so only could be used for Winelib anyway. Mac System 7 Mac System 7.5 Mac System 7.6.1 Mac System 8.0 Mac System 8.5 Mac System 8.6 Mac System 9.x BSDI AIX BeOS HP-UX IRIX Neutrino OpenVMS OS/2 OSF/1 While we're at it, I'd like to add PC-BSD and OpenSolaris. Lastly, how about a compiler keyword, for bugs related to compiler warnings/errors/etc.? -- -Austin

3 4

Re: Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
by chris ahrendt Nov. 14, 2008

Nov. 14, 2008

Stefan D

1 0

Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
by chris ahrendt Nov. 14, 2008

Nov. 14, 2008

Michael / All, Been busy for awhile so have not had the time to work on this patch but here is the 4th try and hopefully final version of the ddraw patch. I took Michaels suggestions and encorporated them into the patch as well. Please let me know if this patch is now ready to submit =) chris

2 1

Re: Bugzilla - Add keyword and remove OS's
by James Mckenzie Nov. 14, 2008

Nov. 14, 2008

Markus: I don't think that Wine will build on MacOS 9 or earlier anymore. James McKenzie -----Original Message----- >From: Markus Hitter <mah(a)jump-ing.de> >Sent: Nov 14, 2008 1:53 AM >To: Austin English <austinenglish(a)gmail.com> >Cc: Wine Developers List <wine-devel(a)winehq.org> >Subject: Re: Bugzilla - Add keyword and remove OS's > > >Am 14.11.2008 um 00:15 schrieb Austin English: > >> Howdy, >> >> The OS list in bugzilla is a bit excessive. [...] >> Mac System 7 >> Mac System 7.5 >> Mac System 7.6.1 >> Mac System 8.0 >> Mac System 8.5 >> Mac System 8.6 >> Mac System 9.x > >You could merge them to "MacOS 9 and before" > > >MarKus > >- - - - - - - - - - - - - - - - - - - >Dipl. Ing. Markus Hitter >http://www.jump-ing.de/ > > > > > >

2 1

Some oddity with kernel32/pipe tests on NT4 and W2K
by Paul Vriens Nov. 14, 2008

Nov. 14, 2008

Hi I'm looking into the timeout issue on NT4. The timeout seems to be coming from: 796 size = 32678; ... 799 ok(CreatePipe(&piperead, &pipewrite, &pipe_attr, size) != 0, "CreatePipe failed\n"); 800 ok(WriteFile(pipewrite, buffer, size, &written, NULL), "Write to anonymous pipe failed\n"); When I change it to write a smaller number of bytes: 800 ok(WriteFile(pipewrite, buffer, (size - 24), &written, NULL), "Write to anonymous pipe failed\n"); we don't have a timeout. Changing the 'size - 24' to a bigger number like 'size - 23' gives a timeout again. Also changing size to 16384 still needs that 'size - 24' in the WriteFile(). In fact every size I use I need a 'size - 24'; I can also make this timeout go away by specifying at least 'size + 24' in the CreatePipe() call. MSDN states that the passed size for CreatePipe us used as an suggestion. I guess NT4 and W2K don't guess/calculate that well? Any ideas? -- Cheers, Paul.

1 0