Throwing in an idea (probably it was discussed before though)

[John Smith]

>Then just tell your users to set that in winecfg, AFAIK winecfg allows app 
>specific settings.

1. It is still not 'out-of-the-box' - and from this point of view it doesn't 
matter much whether it is hacking config file or using GUI; 80% of end-users 
will try it and throw it away if it doesn't work without hacking settings; 
20% of others will ask questions, and will hack config or run winecfg, but 
those 80% will be lost.
2. (not really relevant to this discussion, but relevant to the whole issue 
of supporting end-users): binary RPMs for RedHat/Fedora on winehq.org are 
still 20050524, and winecfg is pretty much useless there. If WINE team does 
care about end-users, it would be nice to have binary RPMs for the most 
popular distribution not that much out-of-date.

>I'm sure your great guys but any such mechanism could be easily abuse by 
>lazy programmers,
Don't see much ways to abuse in general - eventually WINE is supposed to run 
_any_ Win application, right? Also I've suggested that config/winecfg 
per-application settings should override those 'hints', so user is still in 
control of it.

>also once it wasn't needed some sort of backwards compatibility may even be 
>needed,
If all it is about is overriding currently existing settings, no backward 
compatibility is required.

>One simple solution would be to provide default settings for apps that have 
>known problems, Alexandre hasn't ruled that out if it helps some apps to 
>work out of the box.
Ok, this probably is even better; what about integrating such a thing with 
AppDB and automatically include some special field from AppDB data into 
winehq distribuitions?

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/