[Wine] Re: How can we improve WNE?

[man_in_shack]

James Mckenzie wrote:
> 
> 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.


regedit.


James Mckenzie wrote:
> 
> 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.


How about keep winecfg simple? I like this idea better.


James Mckenzie wrote:
> 
> If we advise a user to use regedit and give them complete and comprehensive instructions, they will still mess it up AND blame us.


Then either the instructions are flawed or the user is beyond hope.


> 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.[/quote]

Windows systems don't give the users neat graphical dialogues for every single setting that can be configured. Is that broken? If so, does it make sense to break Wine the same way?


James Mckenzie wrote:
> 
> 
> > 
> > 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.


So delete the pages, or rename it to UselessRegistryKeys. See how many friends you make doing that. Why do the pages exist if it's not for users to look at?


James Mckenzie wrote:
> 
> Remember, if they break Wine, it is OUR fault.


Excellent logic. Flawless. No argument. None at all. Ever. Well done.


James Mckenzie wrote:
> 
> 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.


Making it very easy for people to break something horribly means a lot more effort has to go into supporting the broken stuff, or at least diagnosing it. And, you may not realise this, but diagnosing graphical glitches is hard enough already, we don't need anything to make it more difficult.


James Mckenzie wrote:
> 
> Either we fix the problem or get a real workaround on it.


The problems being talked about are simply not common enough for the changes to winecfg being proposed.


James Mckenzie wrote:
> 
> 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.


Still sounds a lot like "Click here to break everything" to me. Not everything needs to be configurable through winecfg, or winecfg would already be a complete registry editor.


James Mckenzie wrote:
> 
> 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.


"Real fix" is to code. Good luck with that. I dislike the idea of allowing users to hack at settings that should not be hacked at as a quick fix. I dislike the idea of adding settings to winecfg that we know are going to be removed later on. I dislike the idea of dealing with disgruntled users who have broken Wine due to ease of breakage with these settings and then blame us for making it easy to break.


James Mckenzie wrote:
> 
> 
> > 
> > 
> > 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.


Point is you should *never* need to reduce the amount of vid memory under *any* circumstances, even if the "real solution" requires patches to be committed. It's simply a silly thing to do, if not dangerous.


James Mckenzie wrote:
> 
> 
> > 
> > 
> > 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.


These advanced graphics registry keys *ARE NOT COMMON*. We do NOT protect users from changing settings, or we would have a hacked regedit/wineboot that rigidly enforces certain registry keys. We also do NOT need to make it easier for users to break Wine. It's already easy enough.


James Mckenzie wrote:
> 
> 
> > 
> > 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.


Since we're dealing with id10ts, and only id10ts, we should also allow per-application hacks in Wine code so users don't even need to use these advanced settings in winecfg. Built-in application heuristics would prevent a lot of manual tweaking from being needed, but we all know it's not going to happen!

I really think that people like you who say "we need to cater to id10ts (much) more than people with brains" underestimate the average user, and that correctly educating users on how to do things *the right way* is much more productive.


James Mckenzie wrote:
> 
> 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.


And now they're not using Windows, they're using *nix + wine. Education is important. Complete newbs often *have* to be sent to their distro support channels to learn the basic stuff.

Fact is that, as much as things have improved, Wine is not user-friendly. I don't think it ever will be, not because it's "missing" settings in winecfg, but because of the way it works and what it has to deal with. Will we ever get to the point where we can say "pick a Windows app, any Windows app, and it will work in Wine without configuration, tweaking, patches, native DLLs etc."?


James Mckenzie wrote:
> 
> We need to deal with these folks on a professional level.

Are you prepared to pay the supporters on wine-users, forum and #winehq? If not, don't expect "professional-level" support.


James Mckenzie wrote:
> 
> Wine is missing a full winecfg and a Control Panel equivelent.


There is certainly room for improvement, but how much of Wine should be configurable via winecfg or the Control Panel?


James Mckenzie wrote:
> 
> 
> > 
> > 
> > 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.


You seem to be saying there's no point in Wine, or even alternative operating systems such as Linux. It will never work for id10ts (and that's all we care about, right?) so they should just go and buy/install a copy of what they know and love instead.


James Mckenzie wrote:
> 
> 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.[/quote]

Obviously every single option that can be configured HAS TO BE AVAILABLE IN WINECFG THERE IS NO OTHER WAY! REGEDIT IS BAD AND EVIL AND FORCES PEOPLE TO MAKE ERRORS THAT BREAK EVERYTHING REALLY BAD AND IT'S NOT FIXABLE EVER.

No, no, no and no. We do NOT have to provide a simple way to make changes that do little but break stuff. We've already got enough of that.


James Mckenzie wrote:
> 
> winecfg is the place, not regedit, not vi (or emacs if you swing that way).  Get used to it.


These settings are not common enough for the *average* user to give a damn either way. It's very corner-case, "obscure app #34 needs this setting".


James Mckenzie wrote:
> 
> 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.



James Mckenzie wrote:
> 
> As I see it, developers THINK they know it all, which leads to a mess.


Obviously, everything AJ has ever done regarding code quality and correctness at the expense of making things "easy" is wrong.


James Mckenzie wrote:
> 
> 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


I get the feeling from the language you're using that you treat Wine like a corporate entity that only survives on making its users happy. There have been cases where known regressions in released devel versions make them practically unusable, so you get people either complaining their shiny new Wine is broken or that there is no shiny new Wine packaged for them (because the package maintainer won't package the broken release). In these cases, should the release be deferred until the regressions are fixed for the sole purpose of making users happy?

Before anyone decides to reply to this, there's been enough argument going on. We're not getting anywhere; the opinions are too polarised. I'm not saying I should have the last word, but we're just going to keep going around in circles.

Warren: Send your patch(es) to wine-patches and wine-devel. See what the devs say about it. With any luck, it will gain a response from AJ.