Hi Jim,<br><br><div><span class="gmail_quote">On 9/22/06, <b class="gmail_sendername">Jim White</b> <<a href="mailto:jim@pagesmiths.com">jim@pagesmiths.com</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Steven cited the business at Wineconf of Alexandre never being "proved<br>wrong on a technical matter". Another straw man. The part of<br>Alexandre's patch process that is the root of this conflict between Wine
<br>development-focused developers vs. Wine user-focused developers is that<br>which consists of style and aesthetic considerations.</blockquote><div><br>If you want to add a compatibility hack that works for some apps and breaks others then yes its a straw man argument. If you want to have an api implemented properly without anymore compatibility hacks than what Windows itself implements then the current method is the correct one. We've put a lot of effort in to making the Wine user-focus less of a pain. Winecfg has been developed by many developers who are active contributors. Brian Vincent has written 250+ pages of a book on using Wine and the results of his writting have added other developers in areas in finding where we need to make configuration less of a pain. Supporting aesthetic considerations is one thing to say if your talking about a aesthetic consistent platform like Mac OS X. Dealing with Linux with virtually unlimited window managers, styles, themes, etc..ad nauseam...its is a whole different matter.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">CodeWeavers Wine version is full of patches that Alexandre won't accept<br>for WineHQ. Obvious proof that the Alexandre's policy isn't the only
<br>way to make a Wine that people value. In fact it proves that the<br>WineHQ's patch process is not good enough to make Wine that people will<br>pay for, while CodeWeavers' is.</blockquote><div><br>Correct. But while CrossOver Office does contain some hacks in the interest of getting a shipping product out the door with a finite amount of developer time, others use stock Wine with very little tweaking already. Case in point CodeWeavers and Google. As far as I remember there are no hacks that Picasa uses that are not in stock Wine. We have a custom installer and a custom package for running that one application really well but make no mistake about it, picasa should always work on stock Winehq as far as I know. I did not work on that project but I seem to recall all of that. Wine is never going to be able to run EVERYTHING out of the box. If you want that then you need VMware or something. CrossOver adds some spit and polish for a few apps but make no mistake about it. At Wineconf I overheard Jeremy White say at least three times he wished we just did a package of Wine with even less of our value add.
<br></div><br></div>What you and others are asking for is the right to add broken hacks for the sake of user experience. We tried that before with the richedit control which was just a dummy wrapper around the edit control. What happened? No one worked on it for like three years until one of CodeWeavers employees got fed up and in his spare time wrote tests, recruited others and did a lot of the grunt work himself to get work on a proper richedit started. Should we sacrifice more infrastructure for the sake of a few quick hacks for a few applications?
<br><br>-- <br>Steven Edwards<br><br>"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo