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?
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
