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/
Re: Bugzilla - Add keyword and remove OS's
On Friday 14 November 2008 09:53:03 Markus Hitter wrote: 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 What's the point? Wine doesn't run on PPC anyway. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: DIB Engine
В сообщении от Thursday 13 November 2008 13:22:07 Massimo Del Fedele написал(а): Sergey Novosyolov ha scritto: I've already started working on it about 3 months ago and released some functions inside DIB Engine. But now we're thinking about release DIB inside GDI32 as Detlef Riekenberg proposed: On 9/29/08, Sergey Novosyolov [EMAIL PROTECTED] wrote: The first thing, i like to see is a Design in the correct way: Inside gdi32 while using Eng* and friends. (Needed by Printer drivers, and any Display driver including mirror / remote display drivers) why can't we release DIB-Engine as own driver? GDI32 functions are main and GDI32 calls driver functions in dependence of which type of DC we have (printer DC, Xwindow HDC or DIB DC) Any Driver can call the Graphic Rendering Engine (GRE) to do parts (or all) of the rendering (and native driver do that): 1: DDB (Driver managed: using any driver specific format) (The Driver should do Everything. When the driver call the GRE, the DDB is converted to a DIB, GDI renders into the DIB and then the DIB is converted back to a DDB) = like our winex11.drv and wineps.drv 2: DDB (GDI managed: using DIB format) (The driver render, what the driver want to render with hw-support and can call the GRE for all the other rendering without converting) = Needed for native printer drivers / mirror drivers or OpenGL accelerated rendering (stefan did some experiments) 3: DIB (GDI renders everything) = The current Code is using a X11-DDB (Driver Managed) with converting issues. So the conception of new strusture of DIB ENgine inside GDI is needed The question is if we should support native drivers or not, other than winex11 or wineps. For winex11, we're using native rendering functions, for wineps we're just translating GRE calls to ps code directly, no need to convert forth and back. Other stuff would be raw printing, for example, using native drivers but are they really needed ? AFAIK the bottleneck now is the double conversion of DIB-X11 DDB-DIB, in order to be able to use X11 rendering functions, so the point 3. I don't understand your point 1; why convert DDB to DIB ? Driver should render directly into DDB. GDI calls can be directed to native ones. I see it this way (but I could be wrong) : 1) Application uses a DIB format, rendering should be done by DIB driver, conversion is needed only to display it. This is what by now is done with 2 conversions between DIB-X11-DIB formats. As i see if we operate with Display DC we no need to convert and GDI32 calls X11DRV functions directly. If we operate with memoryDC GDI calls DIB functions and then uses BitBlt if needed to reflect memoryDC operations on teh display 2) Application uses accelerated opengl, for example; it must (afaik) use native format and functions to render it. No need to convert anything. what do you mean native format? is it connected with GDI calls? 3) Printer drivers. For ps, they're rendered translating GDI calls into postscript code, for other format the driver should do the rendering. Again, no conversion needed. I agree So, I don't understand why to have DIB engine INSIDE GDI. Function pointers could handle the correct driver calls depending on DIB (or DDB) format. DIB is Device Independent Bitmap so DIB functions would be include those functions which implemented the same independ of device Max From reading all your mails I get the impression that Etersoft is also doing some work on the DIB engine. What work has Etersoft done on this area? It might be wise to post the code somewhere for review before the wrong direction is taken again and it might prevent code duplication. Roderick -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
Re: user32: TPM_ENTERIDLEEX needs to be set for popup windows (resend)
yes, you need ! :D David --- En date de : Jeu 13.11.08, Nicholai Benalal [EMAIL PROTECTED] a écrit : De: Nicholai Benalal [EMAIL PROTECTED] Objet: Re: user32: TPM_ENTERIDLEEX needs to be set for popup windows (resend) À: David Adam [EMAIL PROTECTED] Cc: wine-devel@winehq.org, [EMAIL PROTECTED] Date: Jeudi 13 Novembre 2008, 22h08 Den Thursday 13 November 2008 01:22:14 skrev David Adam: You need to est your email adress in your patches. Ok. I thought that it was enough if the email address was clear in the email. Do I need to resend those patches again?
Some oddity with kernel32/pipe tests on NT4 and W2K
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.
RFC: Wine Icons
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 smime.p7s Description: S/MIME cryptographic signature
Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
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 0001-This-is-the-Fix-for-an-exception-which-occurs-in-dsurf.txt Description: Binary data
Re: Bugzilla - Add keyword and remove OS's
Am 14.11.2008 um 10:15 schrieb Kai Blin: On Friday 14 November 2008 09:53:03 Markus Hitter wrote: 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 What's the point? Wine doesn't run on PPC anyway. Really? http://darwine.sourceforge.net/ MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Bugzilla - Add keyword and remove OS's
Markus: I don't think that Wine will build on MacOS 9 or earlier anymore. James McKenzie -Original Message- From: Markus Hitter [EMAIL PROTECTED] Sent: Nov 14, 2008 1:53 AM To: Austin English [EMAIL PROTECTED] Cc: Wine Developers List wine-devel@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/
Re: Bugzilla - Add keyword and remove OS's
Am 14.11.2008 um 15:11 schrieb James Mckenzie: Markus: I don't think that Wine will build on MacOS 9 or earlier anymore. James McKenzie You might remember a very similar request, just over six weeks ago: http://article.gmane.org/gmane.comp.emulators.wine.devel/63639 It was turned down, then. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
RE: Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
About the content:
With which error code does the surface creation fail? Usually having an
ok(hr == DD_OK) and then catching a failure needs a second look. It isn't
necessarily wrong - there can be a driver bug. However, it is possible that
we're not checking caps well enough and the test doesn't realize that it is
trying to test something unsupported
Style:
The whitespaces on the closing brackets are different from what I remember
from the rest of the file:
if(blabla) {
foofoo
}
vs
if(blabla) {
foofoo
}
You can also avoid the 4 different goto labels if you make sure that the
surface pointers are initialized to NULL, then jump to one err label and
check for NULL before releasing any surface.
-Original Message-
From: [EMAIL PROTECTED] [mailto:wine-devel-
[EMAIL PROTECTED] On Behalf Of chris ahrendt
Sent: Friday, November 14, 2008 2:58 PM
To: [EMAIL PROTECTED]
Cc: wine-devel@winehq.org
Subject: Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in
ddraw test
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
Re: Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
Stefan D
Re: Bugzilla - Add keyword and remove OS's
On Friday 14 November 2008 15:05:41 Markus Hitter wrote: Really? http://darwine.sourceforge.net/ Interesting how wine's website is at http://www.winehq.org/, not at http://darwine.sourceforge.net/ They're a separate project. If there's bugs building darwine on some ancient MacOS version, they should be kept in darwine's issue tracker. I'm getting the feeling you're just poking at this for the sake of keeping the thread going, so I'll back out of it now. Unless you can name a technical reason why Wine would need to keep a bunch of OSes it doesn't run on in Bugzilla, I doubt you'll get much feedback. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
re: Bugzilla - Add keyword and remove OS's
Austin wrote: The OS list in bugzilla is a bit excessive. There are 16 OS's that I think we should remove... 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.
Re: RFC: Wine Icons
Hi Joel, 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. I agree with you, they look pretty poor. 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 opened a bug for the folder icons: http://bugs.winehq.org/show_bug.cgi?id=15810 The problem that I see with the new SVG icon support is that we use icotool to create the small-size icons from the SVG when the SVG is available. This rarely works well. I think we need to maintain hand-drawn small-size icons, and optionally use SVG to generate larger-size (larger than 32x32) icons. Some of the icons, as you say, don't look consistent. You might try bugging Herve, as he's been redrawing all the icons. As far as whether to use Tango, I have no opinion there. --Juan
re: Bugzilla - Add keyword and remove OS's
Sorry for the top post +1 for removing the Pre-X Mac OS's James McKenzie -Original Message- From: Dan Kegel [EMAIL PROTECTED] Sent: Nov 14, 2008 8:35 AM To: Wine Devel wine-devel@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.
Re: Bugzilla - Add keyword and remove OS's
On Fri, Nov 14, 2008 at 9:35 AM, Dan Kegel [EMAIL PROTECTED] wrote: Austin wrote: The OS list in bugzilla is a bit excessive. There are 16 OS's that I think we should remove... 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. Do we even run on the others? -- -Austin
Re: RFC: Wine Icons
forgot CC on first send. On Fri, Nov 14, 2008 at 5:54 AM, Joel Holdsworth [EMAIL PROTECTED] 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
Re: RFC: Wine Icons
Hi Juan, The problem that I see with the new SVG icon support is that we use icotool to create the small-size icons from the SVG when the SVG is available. This rarely works well. I think we need to maintain hand-drawn small-size icons, and optionally use SVG to generate larger-size (larger than 32x32) icons. You're absolutely right. I'm the GUI maintainer for Lumiera, and we're generating our icons from SVGs. Each icon has to be specially adopted for each of the standard small sizes. We've adopted the one canvas icon workflow that Tango artists seem to be working toward. This is a video demonstrating the technique: http://blip.tv/file/1075329 Basically it involves drawing a basic icon, then tweaking it so that it looks good for different sizes. The SVG file is then rigged by putting in invisible bounding boxes marked with XML metadata (this can all be done in inkscape). We then have a python script* that then walks through the SVG, rendering all bounding boxes that it finds marked with the metadata. Here's an example of one of our SVGs: http://www.lumiera.org/gitweb?p=lumiera/joel;a=blob_plain;f=icons/svg/tool-arrow.svg;h=3f0b72102bc3fe846eaedecb2d1ffabe82610aec;hb=master As you can see, the icon has been tweaked to look good at 48x48, 32x32, 22x22 (24x24 is also produced from this size), and 16x16. The One Canvas Workflow makes it very easy to make consistent changes instead of having to keep hundreds of different files in synch. You might try bugging Herve, as he's been redrawing all the icons. I find that a bit alarming. I'm sure he's working very hard, and doing good stuff, but I don't think Wine should be redrawing anything. Not when we have Tango around - it's designed to try create some consistency through standardisation. IMO standards are really good! - we use them if we possibly can. Joel * see here: http://www.lumiera.org/gitweb?p=lumiera/joel;a=blob;f=admin/render-icon.py;h=26bdb36535fb70464b1db5d217d007d571519db6;hb=master smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Wine Icons
On Fri, Nov 14, 2008 at 9:43 AM, Branan Riley [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 5:54 AM, Joel Holdsworth [EMAIL PROTECTED] 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 Thinking about this a bit more, it would require a tool to generate the .DLL with the icons we want from the freedesktop spec, in order to maintain compatibility with Windows on how system icons are handled. This could be done once when the prefix is created, with an option in winecfg to re-build the icon DLL.
Re: RFC: Wine Icons
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
Re: RFC: Wine Icons
I'm the GUI maintainer for Lumiera, and we're generating our icons from SVGs. Each icon has to be specially adopted for each of the standard small sizes. We've adopted the one canvas icon workflow that Tango artists seem to be working toward. This is a video demonstrating the technique: http://blip.tv/file/1075329 That video didn't work for me. Basically it involves drawing a basic icon, then tweaking it so that it looks good for different sizes. The SVG file is then rigged by putting in invisible bounding boxes marked with XML metadata (this can all be done in inkscape). We then have a python script* that then walks through the SVG, rendering all bounding boxes that it finds marked with the metadata. Interesting. That might be worth trying to get into our build process. Care to have a go? I find that a bit alarming. I'm sure he's working very hard, and doing good stuff, but I don't think Wine should be redrawing anything. Not when we have Tango around - it's designed to try create some consistency through standardisation. IMO standards are really good! - we use them if we possibly can. The trouble is that the Tango icon set doesn't cover all the icons Wine needs. There's no Tango icon for regedit, for instance. While I agree with you that as a general rule, we should try to use available and applicable standards, sometimes there's something more expedient we could be doing. The basic problem you bring up is an inconsistent look for icons. There are two general solutions proposed: use Tango icons, and use a combination of theming and fd.o icons. There's something simpler we can do too, which is to have someone draw all the Wine icons with a consistent look. They won't necessarily match whatever desktop environment you're running in, but least they'll be consistent with one another. This, I believe, is what Herve's trying to do. But anyway, I'm not working on any of this stuff. Wine's driven by our contributors. If you'd like to see it done differently, by all means send patches! --Juan
Race in thread shutdown in imm32?
I'm seeing the following valgrind warning in three out of eight runs under heavy load: InvalidRead IMM_FreeThreadData:233 DllMain:382 __wine_spec_dll_entry:40 MODULE_InitDLL:911 LdrShutdownThread:2174 call_thread_func:403 start_thread:444 It kind of feels like a race between thread shutdown and process shutdown. Does that ring a bell with anyone? - Dan
Re: imm32: implement ImmInstallIME(W/A)
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
Re: RFC: Wine Icons
Am 14.11.2008 um 18:46 schrieb Branan Riley: On Mac, you should use the native mac icons, but that might not work to do Obj-C issues On the Mac, icons are stored in separate files, so there's no need for system calls or Obj-C. Find them with find /System -name \*.icns Unfortunately, they are in the uncommon ICNS format. Here's a procedure to convert them to the PNG format: http://slaptijack.com/graphics-design/converting-mac-os-x-icon-files- to-png/ I have the sips tool mentioned there installed, so it's likely part of the standard distribution. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
ComputeSphereVisibility: a patch
Hi, here is a patch for a first try to implement ComputeSphereVisibility. Any feedback is welcome. David 0001-ComputeSphereVisibility.patch Description: Binary data
Governance of Wine with respect to the Software Freedom Conservancy
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
Re: Race in thread shutdown in imm32?
2008/11/14 Dan Kegel [EMAIL PROTECTED]: I'm seeing the following valgrind warning in three out of eight runs under heavy load: InvalidRead IMM_FreeThreadData:233 DllMain:382 __wine_spec_dll_entry:40 MODULE_InitDLL:911 LdrShutdownThread:2174 call_thread_func:403 start_thread:444 It kind of feels like a race between thread shutdown and process shutdown. Does that ring a bell with anyone? IMM_FreeThreadData can crash if TlsGetValue returns a NULL pointer. On first glance, it doesn't appear possible as IMM_InitThreadData is called for every thread and on process startup. However, as you surmise, it is possible in Wine for a thread to exit after the main process has shut down (i.e. TlsFree(tlsIndex) has been called) and the TLS area has been cleared, causing TlsGetValue to return 0. I believe that Windows terminates all threads on process exit, which would solve this problem. However, the issue could trivially worked around by introducing a NULL pointer check in IMM_FreeThreadData. It would also be a good idea to set tlsIndex to TLS_OUT_OF_INDEXES after TlsFree is called to avoid the possibility of using an un-allocated TLS index. -- Rob Shearman
Re: OLEAUT32: implement OleLoadPictureFile(Ex) and add tests
On Mi, 2008-11-12 at 23:40 -0800, Jeremy Drake wrote: I have no Idea about that area, but the unicode API is not implemented on win9x (GetTempFileNameW, CreateFileW, DeleteFileW) if(!pOleLoadPictureFile || !pOleLoadPictureFileEx) Are there systems in the Wild that have OleLoadPictureFile, but are missing OleLoadPictureFile? In that case, you should use 2 seperate tests. skip(Skipping OleLoadPictureFile tests\n); Think, what you would see in the log before your text: filename.c:__LINE__: Tests skipped: Skipping is redundant and tests also. The usual way would be: skip(OleLoadPictureFile not found\n); When you want to make sure, that we never skip in Wine here, then use win_skip instead. -- By by ... Detlef
Re: Revert quartz: Reaching a renderer in the filtergraph is not an error.
On Fri, Nov 14, 2008 at 1:54 PM, Maarten Lankhorst
[EMAIL PROTECTED] wrote:
This is plain wrong, input pin and output pin are supposed to be connected
to each other, not the input pin being connected to a renderer pin and NOT
reaching output pin
---
From 0f91e8a67c88d1ec0871c772679871249fd7625f Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst [EMAIL PROTECTED]
Date: Fri, 14 Nov 2008 22:50:34 +0100
Subject: [PATCH] Revert quartz: Reaching a renderer in the filtergraph is
not an error.
This reverts commit 62a0bd65d2fe9febd6928ff5912e84a34f76a97f.
---
dlls/quartz/filtergraph.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/dlls/quartz/filtergraph.c b/dlls/quartz/filtergraph.c
index b249724..c53771e 100644
--- a/dlls/quartz/filtergraph.c
+++ b/dlls/quartz/filtergraph.c
@@ -1042,8 +1042,9 @@ static HRESULT WINAPI
FilterGraph2_Connect(IFilterGraph2 *iface, IPin *ppinOut,
if (SUCCEEDED(hr)) {
unsigned int i;
if (nb == 0) {
-TRACE(Reached a renderer\n);
-break;
+IPin_Disconnect(ppinfilter);
+IPin_Disconnect(ppinOut);
+goto error;
}
TRACE(pins to consider: %d\n, nb);
for(i = 0; i nb; i++)
--
1.5.6.5
Correct, I got this one wrong. Please revert my patch and apply
Maarten's patch to fix infinite recursion.
Re: RFC: Wine Icons
On Fri, Nov 14, 2008 at 9:43 AM, Branan Riley [EMAIL PROTECTED] wrote: On Fri, Nov 14, 2008 at 5:54 AM, Joel Holdsworth [EMAIL PROTECTED] 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 Thinking about this a bit more, it would require a tool to generate the .DLL with the icons we want from the freedesktop spec, in order to maintain compatibility with Windows on how system icons are handled. This could be done once when the prefix is created, with an option in winecfg to re-build the icon DLL. Recently I posted a sample on how to generate windows themes (.msstyles). These themes also support icons and icons can be added to it. There is a section for them but I haven't really looked at those but it shouldn't be hard. Dlls that use icons should use uxtheme to get access to icons when theming is enabled. For now I think that there should just come some basic color and icon themes. Creating theme files at startup is tricky as either you need to compile them to a .dll (or .dll.so) OR you need an empty dll in which you inject icons which is very evil. Roderick -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
Re: gdiplus: fix GdipFlattenPath for already-flat paths and add a test
Please ignore this patch. It has a line removed that shouldn't be. Vincent Povirk On Fri, Nov 14, 2008 at 5:07 PM, Vincent Povirk [EMAIL PROTECTED] wrote:
Re: OLEAUT32: implement OleLoadPictureFile(Ex) and add tests
On Fr, 2008-11-14 at 21:17 +0100, Detlef Riekenberg wrote: On Mi, 2008-11-12 at 23:40 -0800, Jeremy Drake wrote: if(!pOleLoadPictureFile || !pOleLoadPictureFileEx) Are there systems in the Wild that have OleLoadPictureFile, but are missing OleLoadPictureFile? In that case, you should use 2 seperate tests. skip(Skipping OleLoadPictureFile tests\n); Think, what you would see in the log before your text: filename.c:__LINE__: Tests skipped: Skipping is redundant and tests also. The usual way would be: skip(OleLoadPictureFile not found\n); When you want to make sure, that we never skip in Wine here, then use win_skip instead. Forget that. I just read the Mail about the disassembly usage. -- By by ... Detlef
Valgrind warning in wined3d/swapchain.c in IWineD3DSwapChainImpl_Destroy
Hi Stefan, you seem to have been in this code recently, could you have a look? This is a somewhat flaky error that happens about 80% of the time under heavy load on my quad core box. (This is valgrind's xml output format, it's pretty fluffy, sorry.) Thanks, Dan error kindUninitCondition/kind whatConditional jump or move depends on uninitialised value(s)/what stack frame objdlls/wined3d/wined3d.dll.so/obj fnIWineD3DSwapChainImpl_Destroy/fn dirdlls/wined3d/dir fileswapchain.c/file line75/line /frame frame objdlls/d3d9/d3d9.dll.so/obj fnIDirect3DSwapChain9Impl_Release/fn dirdlls/d3d9/dir fileswapchain.c/file line66/line /frame frame objdlls/d3d9/d3d9.dll.so/obj fnD3D9CB_DestroySwapChain/fn dirdlls/d3d9/dir filedirectx.c/file line427/line /frame frame objdlls/wined3d/wined3d.dll.so/obj fnIWineD3DDeviceImpl_Uninit3D/fn dirdlls/wined3d/dir filedevice.c/file line2426/line /frame frame objdlls/d3d9/d3d9.dll.so/obj fnIDirect3DDevice9Impl_Release/fn dirdlls/d3d9/dir filedevice.c/file line98/line /frame frame objdlls/d3d9/tests/d3d9_test.exe.so/obj fnfunc_visual/fn dirdlls/d3d9/tests/dir filevisual.c/file line9960/line /frame frame objdlls/d3d9/tests/d3d9_test.exe.so/obj fnrun_test/fn dirdlls/d3d9/tests/../../../include/wine/dir filetest.h/file line452/line /frame frame objdlls/d3d9/tests/d3d9_test.exe.so/obj fnmain/fn dirdlls/d3d9/tests/../../../include/wine/dir filetest.h/file line502/line /frame /stack /error
