man_in_shack <
[email protected]>
Sent: Apr 8, 2009 9:37 AM
To:
[email protected]
Subject: [Wine] Re: How can we improve WNE?
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.
Again, these folks are IDIOTS and should not be let anywhere near this stuff. KISS is a princple that has to be pounded into some developers. I'll let you guess which category you are in. If you can provide a simple, easy to use graphical interface, that is MUCH better for them. BTW, I work with these people on a daily basis and you would be amazed that they want a PowerPoint presentation, with bullets, or you don't get what you want. Sure a simple e-mail message would get the point across but you have to work with what you have to work with.
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.
I agree, but in the meantime, while we work through the problems, give the users what they need to get their programs working.
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.
I'll take number two. However, these are the same users that plaster every blog in the blog-o-sphere with how bad Wine is. I have to bring forward something that I was told in my marketing class in college: A person who has a bad experience and feels that nothing was done will tell 100 of their friends about it (and this means the man-in-the-street as well); a person who has a good experience will tell four. This is what we have to overcome. Again, if you want Wine to be your hobby, continue pissing off users and that is what it will become. Most of the people here want people to use the product, have a good experience and tell their friends.
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.
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?
[/quote]
Of course, Windows does not give you the ability to change each and every setting, nor should Wine. However, settings that fix problems should be easy for users to find and set, with WARNINGS. This way, when a user comes to us, we can say "We warned you and you did it anyway". Right now, people are going through the archives, visiting the Applications Database and breaking Wine and then blaming us, rightfully so.
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?
We should have this information in the FAQs, where needed, and in the Applications Database. That is where we should be sending users, not to a page full of registry keys. Again, KISS is the word here and we are dealing with IDIOTS. If you get that, then the rest is easy.
James Mckenzie wrote:
Remember, if they break Wine, it is OUR fault.
Excellent logic. Flawless. No argument. None at all. Ever. Well done.
You got the user point of view or you are being seriously sarcastic. I've been in customer service for over 30 years. The streams of obsenities would make your hair curl from some users. And guess what, I was not kidding. That is how the average user sees things. "You told me to go to page XXX in the manual, I followed each instruction with extreme care, your program does not work, fix the xxxxx or give my my money back." I've been there, and I've had to send them to the refund department to get their money back. A few of these phone calls can make your day.
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.
You underestimate my capabilities, my friend. For instance, I work in the industry and applied a patch to a well known product yesterday that broke our processes. I have vendor support coming in today to fix it. This is frustrating, but it is something I deal with on a day to day basis. I'm well paid to do this. We don't need to fost a partial product on unsuspecting users without a method to help them. And dealing with graphic problems is what we are here to do. Users should have a simple way to make changes. Running them through regedit is not easy and subject to causing massive problems.
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.
I understand the situation. Yes, winecfg needs to be worked on and this should be the method for now.
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.
I agree. What I'm saying is if a user has to change a commonly known setting, it should be available through winecfg. If it is not well known or deprecated, then it is time to get into regedit and only by knowledgable users.
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.
I agree that the proper method is to fix the code. I also don't like for users to 'crack' around, but sometimes that is the ONLY solution to the problem that works. I don't like adding and removing things from a working program, but remember we are dealing with folks who don't even know what the registry is and they really don't care how it works. All they want (as Austin has pointed out) is for their favorite program to work. Be it Office 2007, WoW, dOOm III, or any other program. If we make it easy for them to get it running, that is much better. There will still be users that will want to see what happens when they click that button, and a warning message is not what they expect. If we do this, some will charge on, but they have been warned and we can state so when they do. If we put messages with registry settings here, an archive search will cause all sorts of problems.
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.
Yet users complain that we hide stuff from them. Go figure that one out.
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!
You have got to visit the unoffical Wine repositories. There is a wealth of knowledge about hacking/cracking Wine that is to be gained. You will see hacks that will NEVER make it into Wine due to AJs controls. And I am glad they are there.
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.
Good luck with that thought. There are users out there that will jump on and abuse you in ways you never thought possible. Like I said, there are users that are attempting to use Linux/Wine that have difficulty grasping the concept of what the power button does. All they want to do is start the computer, click a few buttons and play away. Anything more than that is beyond their capabilities. I'm serious about this.
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.
See my comment above. Take a look at the Ubuntu user support forum. It's scary how ignorant some users are.
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."?
I agree. At one time it was said "DOS is not done until Lotus will not run." We are trying to work on a moving target and it has been this way since WinNT 3.5 was released (I worked on Project Oddin for OS/2 otherwise known as WinOS/2.) It would be great to be able to run any application, but that is not going to happen. We have to pick the most popular and go from there. The popularity list changes as new games are released and old ones are retired.
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.
No, but then again, I bought CrossOver for Mac. And I plan on keeping up support to Jeremy and company. That is when I can complain about something not working.
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?
The same amount as is in msconfig and Control Panel. Users should not have to dig through the registry to make known changes.
austin987 wrote:
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.
I'm saying that we need to know when to tell someone that what they have will not meet their needs. That is what I do for a living. If a person does not display the ability to handle Linux and/or Wine or is frustrated with the lack of support for their favorite program, it may be time to tell them to install WindowsXP. If they can be guided, then we should help them, no matter what level they are at.
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.
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.
[/quote]
Did I state that? No. Winecfg should contain only those settings needed to get programs running and after a warning is displayed that other programs may and will break.
The real fix is to change code to get the programs working. Winecfg is a workaround.
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.
And we have users whining about how to use the regedit. Remember, not everyone knows how or even wants to learn how. That is called arrogance and it REALLY is not good. We have to deal with problems from the user point of view. I know that is hard, but it has to be the trait of any good programmer.
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".
For some users, regedit is not scary. For some users, they have been told, rightfully, never, ever use regedit. Those are the users we have to have a solution for. You got one, and it CANNOT include the words, "take this file and run regedit against it". Won't happen, ever, for that user and they will walk away stating "Wine Sucks and the people who support it suck too." If we can say, go to the XX tab on winecfg and click this setting, they will do it. Of course, we will have to warn them that bad things can and will happen.
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.
No, he has kept the code CLEAN. Easy is not his job. Correct and proper is. There is a vast difference.
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?
I'm not at that level of decision making. But I will ask you this: Would you release a program into the credit industry that would not process one of the big card issuers cards? That has happened. There was a real quick fix to the problem. If you are working with development level programs, you should expect problems. If you are working with release level code, there should be no 'show stopper' bugs, like Office 2003 not installing properly. Keep this in mind.
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.
You are correct here. Your attitude is that every Wine user should learn how to use regedit. Mine is much different because I have years of dealing with customers. One thing I will leave you with:
The Customer is the reason we are here today. WE must meet the customers needs and desires. Failure to do so will mean that we will NEVER see that customer again. Customers are ALWAYS right. They may be mis-informed, ignorant, stupid or even stubborn, but they ARE ALWAYS right.
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.
Please do. AJ has the sole right to reject any patch for any reason he sees fit. And I respect his right to do so.
James McKenzie
