[Wine] How can we improve WNE?

[James Mckenzie]

man_in_shack <wineforum-user at winehq.org> wrote on April 8th:
>
>austin987 wrote:
>> 
>> VideoMemorySize I'll agree with you on. If that is left in the
>> registry, I won't disagree.
>> 
>> OffscreenRenderingMode, however, is a fickle beast, and depending on
>> the application, fixes tons of problems, or yes, causes random
>> crashes. But as I've said, the same can be said for native dlls
>> (comctl32/dcom98 are especially bad here). We don't play the
>> babysitter for most other settings (only _really_ dangerous ones,
>> e.g., changing C:\ to point to a windows install, or running with
>> sudo). Changing the OffscreenRenderingMode is no more dangerous than a
>> native DLL, and IMHO deserves no special treatment just because it's a
>> graphic setting rather than a DLL setting.
>
>
>Can already be done. May not be easiest thing to do, but can already be done via regedit.
>
But we are asking users that have a tenatous grasp of how to power on a computer to edit files that they should not even be touching.  I think the 'best solution' is to offer these settings via winecfg, until they are no longer needed or desired.  Have winecfg do the 'behind the scenes' work to make the changes.  Remember that we should follow the KISS principle:  Keep it simple and stupid.  If we advise a user to use regedit and give them complete and comprehensive instructions, they will still mess it up AND blame us.

>At least native DLLs are more predictable than changing OffscreenRenderingMode. They're also more
>important to support, as there are obvious deficiencies in Wine (e.g. gdiplus and d3dx9_##) that
>currently can't be resolved without native DLLs, due to completely missing implementations. Before
>you argue that there's no way to resolve some games without OffscreenRenderingMode, it's not quite
>the same category. In theory, with enough work, any OffscreenRenderingMode would work with any
>game. In practice, we know this is not the case.

This is a defincency of both Wine, due to the lack of implementation, and of Windows, for poor coding practices.  The best solution is to 'break' Wine in the same way that Windows is.  The trick is that Windows has about 20 years head start.
>
>
>It's not the easiest or most obvious thing to force a DLL override to native in winecfg (not even
>obvious to make it native,builtin). We also say "here, change the registry settings for advanced
>Direct3D and OpenGL stuff manually, you're smart enough to figure it out with the
>UsefulRegistryKeys page on the wiki" already. So, the argument doesn't seem hypocritical to me. If
>anything, it's *easier* to change the settings according to UsefulRegistryKeys than it is to set
>native DLLs, just due to the wording in the Libraries tab.

We should not be sending users to these pages.  Remember, if they break Wine, it is OUR fault.  Been there, done that.  And the results are not 'pretty'.  We want to put our best effort into this project and the above paragraph has the word "LAZY" written all over it.  Either we fix the problem or get a real workaround on it.  Editing the registry should ONLY be done if NOTHING else works, period.  If we can provide an interface through winecfg, then that is where it should be.  Of course, we can add the warning that using these changes can and will break your Wine for one or more applications, may back some folks off, but others will charge ahead.  And when they break Wine, we can come forth with "You were warned and you went ahead and did it anyway" and then follow up with the real fix.

>
>
>austin987 wrote:
>> 
>> Winecfg exists to make changing Wine settings easier on users. There
>> is _nothing_ in winecfg that can't be done in the registry or
>> elsewhere (the drives must be done via terminal/file manager).
>
>
>You're absolutely correct! Do you know what that means? There is *no reason at all* to
>provide "advanced" settings in winecfg. Users who need them can use regedit, just like they'd have
>to do on Windows for equally advanced settings.

I don't edit my registry on Windows.  I use tools for that (msconfig anyone).  That is the purpose that winecfg should fill.  If I need to lessen the amount of video memory, I should be able to do this through winecfg, not through regedit.
>
>
>austin987 wrote:
>> If we want to protect users from changing Wine,
>
>
>We don't. You already said you can change this stuff via the registry. It just doesn't need to be
>made any easier; the settings simply aren't that reliable or common enough to go in winecfg.

Really?  I don't think so.  Many conversations on users rotate around configuration settings and how to set them.  Sure, you should not be able to change EVERY setting, but the more common ones should be there.  Again, user warnings should be there too.
>
>
>austin987 wrote:
>> Until
>> that's done, there _is no_ merit in saying that we shouldn't allow
>> changing graphics settings. Again, I _know_ that progress is close to
>> it not being needed. The same was said with the ddraw rewrite, which,
>> even though it is nearly 3 years old, still has regressions. Winecfg
>> is there to make adjustments easier on users, graphics tweaks are
>> typically needed for games, and allowing changing those settings makes
>> sense.
>> 
>
>
>Wine already does very well not requiring graphics tweaks for games. In fact, graphics tweaks are
>not required for 99% of the games I've *ever* tried to run in Wine (one game requires ddraw
>renderer to be set to opengl, another looks marginally better if OffscreenRendererMode is set to
>fbo). Again, I question the suggestion that these settings are common enough that they should be
>available as settings in winecfg.

Again, I question why they are not there.  We are dealing with ID10Ts in some cases that installed Linux and Wine to run games that are freely available in a Linux version.  Why?  Because all they know is Windows.  They grew up with it and they could not even tell you, without prodding, what video card they are using.  We need to deal with these folks on a professional level.  Wine is missing a full winecfg and a Control Panel equivelent.
>
>
>austin987 wrote:
>> 
>> Working in #winehq/the forums a lot, I've got a bit less of a
>> developer mentality.
>
>
>As a regular supporter in #winehq, I do *not* want to see a new wave of users going "my app is
>broken" where the solution is "don't use those advanced graphics settings; hit the reset button".
>That is my main concern with making it easy to change values that, in general, should never be
>changed.

ID10Ts will always be there.  You just have to deal with them or ignore them.  The best line I seen here is: "If you wanted to run Windows, go to your local store, buy it and install it.  Linux never has been nor will it ever be."  Sadly, Windows is and will be the solution for most computer users.  I remember the day when knowing the secret Lotus 1-2-3 startup settings made you a guru, although they were freely available and even on the hints card.  
>>
>austin987 wrote:
>> 
>> While I see both sides of the argument, I get the
>> feeling many developers forget that users are using Wine to get work
>> done/play their game/use their application. What's in the future is
>> unimportant. They simply want to use it now. If we want to encourage
>> that, like already do by including winecfg, then there's no reason we
>> shouldn't add these graphics tweaks. If not, then remove winecfg, or
>> even remove the tweaks that can be dangerous, to eliminate the
>> hypocrisy.
>> 
>> -- 
>> -Austin
>
>
>What you're talking about is essentially a quick hack to fix a handful of problems, hiding the bugs instead of fixing them. Wine devs don't like doing that.
>
I've met developers that don't even like looking at bug reports from testers.  We have to provide USERS (they are why we are here unless we want to be a bunch of hobbyists) with a simple way of making changes.  winecfg is the place, not regedit, not vi (or emacs if you swing that way).  Get used to it.  When we fix a problem, we remove the setting from winecfg and ignore any changes made to the registry.  This makes the user experience better and we can direct them how to make changes without having to send mumbo-jumbo to them that they continuously mess up.  As I see it, developers THINK they know it all, which leads to a mess.  Let's get the solution where it needs to be, in the product.  I agree that making these changes covers up the bug, but users are not going to wait a year or two for a bug to be fixed.  They want a solution, and they want it TODAY.  So, let's give it to them.  I live by the accumen:  Changes are possible, but do we really want to make that change?  At this point, yes we should change winecfg.

James McKenzie