How can we improve WNE?

[austin987]

On Wed, Apr 8, 2009 at 3:24 PM, fcmartins <[email protected]> wrote:

man_in_shack wrote:

The solution to the above problem is separate wineprefixes, but if the intent is to make it *easy* to configure, then that doesn't help.

Sorry, but even if the general consensus of developers was "Yes, we should make it easier to change all these settings", the user supporters would then have to deal with brokenness of individual configurations akin to installing apps via ies4linux or wine-doors, or if someone thinks it's a good idea to install MS DirectX in wine.

This touches on another area of Wine weakness regarding usability. Although adding more options would aggravate the situation, as it stands, winecfg already allows for a change in a setting to mess up the next or previously installed application.

IMO, ideally, Wine(cfg) would support configurations per application. It just looks silly that I have to change settings each time I run an application that needs different settings from the previous. (of course, by then I already forgot which were the original settings I used).

It does, to an extent. You can set windows versions/dll
overrides/virtual desktops and a couple other things to be 'per
application'. Sound drivers cannot be.

I'm not sure the solution has to lead necessarily to different wine prefixes. Maybe it is sufficient to keep in the registry a set of winecfg settings per application (.../wine/winecfg/app_name/setting) which would be automatically re-set before the app is run.

Anyway, I think the concept of a wineprefix per application can be reasonably accepted by the users AND made transparent. Ideally winecfg would facilitate different wine prefixes, but this is arguable, i.e., maybe it falls better under the domain of "wine distributions".

winecfg can't do this, it is a winelib application, and is only aware
of the wineprefix it is running in. You'd have to have a non winelib
application do this. This is what, e.g., Crossovers' bottle manager,
PlayOnLinux, and Bordeaux do.

--
-Austin

[tparker]

fcmartins wrote:

James, I fully share your viewpoint, but I have to disagree with the use of the word "idiots"

I will chime in as an idiot who often has to come to the list to beg for
ideas to fix problems that, to those with the knowledge, are trivial.

When it comes down to it, I am an end user. I use my computer for basic
things - email, web browsing, TV shows, music, and video games. Those
are the same things I used Windows for. I never did anything in Windows
that made me have to learn about the actual software workings of the
computer and when something doesn't work in Linux I have absolutely no
frame of reference to fall back on or compare things to in order to fix
the problem. People say 'regedit is the same as in Windows' but that
doesn't help someone who never used it there.

Then once the problem is fixed it all works great until I update
something. I may need the same fix after the update as I had used
before, but it's several months later and I no longer remember anything
about what to do, so I have to ask again. The forum has been a huge help
with this since I can now go there and search for the old fix but it
does still happen for questions asked pre-forum.

the users might just be ignorant

This is often the case, even for those of us who try the db, google, and
other forums for answers before asking for help. Often times we find
just enough information to tell us what the problem is, but not enough
to tell us how to fix it. To quote man_in_shack's earlier post:

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

I run into flawed instructions very often as a newbie. Okay, flawed may
not be the correct term, maybe 'not specific enough'. Sometimes a fix
will say "edit Y file and add Z", but I don't know how to find Y file
and when I do find it I don't know what part of the many lines in it to
add Z to. I have often broken my computer trying to follow directions
that were just shy of specific enough for an uneducated (in computers)
user. When I find someone who knows more than I to help me fix it they
ask why the heck I did something so stupid and the answer usually is
that I didn't know better.

Searches often fail because I know what I need to find, but may not know
the best key words to search for, so I end up spending an hour reading
through stuff I don't need and grabbing terms from those pages to refine
my search enough that I can hopefully get to what I do need. By the time
I give up and post for help I am so confused that I'm not even sure how
to word what I need anymore.

The above quote was referring to regedit. For me the Useful Registry
Keys instructions took about thirty minutes of google searches and
webpage reading before I could even start following them. Most of the
time was going through the pages to find one in dummy speak to tell me
what regedit even was so I could figure out if I needed to try it. Then
trying to learn enough to know what keys in the list I should try.

This has also been improved as more detailed instructions are added to
the wiki, hopefully that continues. I live in dread of having to update
my wine again, my currently stable install is from a wine-git that took
me 3 days of tears and caffeine to figure out and even with the notes I
took along the way and I know that I can not repeat the steps without help.

Idiots may be a bit harsh, but I can't say it's always wrong either.
Particularly when used by someone who spends a great deal of time saying
the same things over and over as each new person runs into a problem
that needs the same fix someone else needed last week. Even though I
know the people who cut me off on the highway each day aren't all
idiots, I still call them all that after it happens enough times.

[fcmartins]

winecfg can't do this, it is a winelib application, and is only aware
of the wineprefix it is running in. You'd have to have a non winelib
application do this. This is what, e.g., Crossovers' bottle manager,
PlayOnLinux, and Bordeaux do.

You mean neither of the 2 "solutions"? I know too little about wine operation, but I was seeing winecfg just as the the tool to manage configurations. The wine launcher would check the stored configuration for the app (if any), setup the registry accordingly, and only then launch the application.

[austin987]

On Wed, Apr 8, 2009 at 5:42 PM, fcmartins <[email protected]> wrote:

austin987 wrote:

winecfg can't do this, it is a winelib application, and is only aware
of the wineprefix it is running in. You'd have to have a non winelib
application do this. This is what, e.g., Crossovers' bottle manager,
PlayOnLinux, and Bordeaux do.

You mean neither of the 2 "solutions"? I know too little about wine operation, but I was seeing winecfg just as the the tool to manage configurations. The wine launcher would check the stored configuration for the app (if any), setup the registry accordingly, and only then launch the application.

Could you be more clear please?

--
-Austin

[man_in_shack]

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.

Settings clutter.

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.

Feel free to create a bunch of PPTs for AppDB instructions and FAQ entries. Obviously, they are NEEDED, because we HAVE TO CATER to the id10ts that use Wine, right?

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

I agree,

Resolved. Argument over.

but in the meantime, while we work through the problems, give the users what they need to get their programs working.

Can't keep winecfg simple *and* add a bunch of settings in the mean time.

I have to bring forward something that I was told in my marketing class in college:

When did Wine get a marketing department? And when were you appointed its director?

Wine does very well increasing its user base without traditional marketing already, just like other opensource projects.

continue pissing off users

Because that's exactly what I'm *trying* to do, right?

Most of the people here want people to use the product

Which they buy with money, and pay continuing service and support fees, right? Oh wait, Wine doesn't cost money, nor does it cost for support. You have a very business-related viewpoint which I feel is irrelevant to Wine and opensource in general.

Of course, Windows does not give you the ability to change each and every setting, nor should Wine.

So let's not do it then. Argument over.

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".

And they can say "WHAT WARNING IT WASN'T BIG ENOUGH I DIDN'T SEE IT WINE SUCKS". It's just harder for them to say it, but remember, these are id10ts, because we only care about id10ts.

Right now, people are going through the archives, visiting the Applications Database and breaking Wine and then blaming us, rightfully so.

You're an AppDB admin, so fix AppDB.

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.

This is how it works:
User: "It's broken!"
Supporter: "Did you check AppDB?"
User: "Yes, no help. Here's the error I get: blah blah"
Supporter: "Hmm, try changing this setting with regedit. It's listed in UsefulRegistryKeys. You want this specific option."
User: "Thank you. Wine is awesome and so is everyone who supports it."

or:
User: "AppDB tells me to change this setting but I can't find it."
Supporter: "It's listed in UsefulRegistryKeys. You want this specific option, and you need to edit it with regedit"
User: "Thank you. Wine is awesome and so is everyone who supports it."

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."

They're welcome to ask WineHQ for their money back. I'm sure everyone involved will be willing to help them reclaim every cent they paid WineHQ for Wine.

We don't need to fost a partial product on unsuspecting users without a method to help them.

Sorry, but that's what we have to do. Wine *is* by nature an unfinished, unfriendly, partial "product". Even (especially?) stable branch is like that.

BY NATURE, not something that can be fixed by adding a bunch of settings to winecfg ... unless you WANT settings clutter.

And dealing with graphic problems is what we are here to do. Users should have a simple way to make changes.

I've worked out what's going on here, see below.

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.

Resolved. Argument over.

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.

In that case, we want EVERY SINGLE KEY listed on UsefulRegistryKeys to be editable by nice pretty UI via winecfg. No one is arguing for this though; it's restricted to the Graphics tab. All of the keys on UsefulRegistryKeys are well known and (almost all) are not deprecated, or going to be deprecated any time soon.

"Real fix" is to code.[/quote

I agree that the proper method is to fix the code.

Resolved. Argument over.

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.

Resolved. Argument over.

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.

Maybe we could do a deal with Microsoft that allows us to subsidise copies of Windows to Wine users, and ship VirtualBox or dual-boot bootloaders instead of Wine.

users complain that we hide stuff from them. Go figure that one out.

Then they should be digging around in the source code, the registry, the wiki for the information we're "hiding" from them. We're not hiding anything. Again, the users in question are defective, and we shouldn't have to support them.

You have got to visit the unoffical Wine repositories.

Which are not supported by WineHQ. Awesome argument. Well done. You win the internet.

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.

So you're also saying it needs to be easy for the average id10t to patch and compile Wine if it will make their app better? Or are you saying that some (or all) of these "unofficial" hacks need to be merged into Wine purely for the reason that they make more apps run?

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.

WineHQ does not support ACPI shutdown states, electrical current control, or the buttons and/or switches used to modify either of these things. If they're struggling to find their power button, they need to do some learning external to Wine and come back later. It makes it easier on *everyone*, not just the supporters.

See my comment above. Take a look at the Ubuntu user support forum. It's scary how ignorant some users are.

Agreed.

I agree.

Resolved. Argument over.

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.

This is what I meant when I said earlier I worked out what's going on. You're confusing Wine with Cedega, and WineHQ with Transgaming. Every single one of your arguments makes sense when applied to Cedega.

Sorry, but no, Wine does *not* have to support the "most popular" of anything. Wine is intended to be a complete implementation of win32. Wine devs don't generally go about fixing stuff "because it fixes this application", it's about fixing stuff "because this API doesn't work correctly". Maybe the most popular/common applications get "fixed" faster, because it's more obvious to the devs that they are broken. It's easy to download a small demo app or test case that demonstrates brokenness in Wine, not so easy to dig up some obscure title from 15 years ago that never had a freely released trial or shareware version.

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.

Good on you! One snag though, CrossOver is not Wine, and Codeweavers are not WineHQ. I'm fully aware of the work that Codeweavers put into Wine, and very appreciative of it, but purchasing a copy of CrossOver does not give you license to complain about how Wine works. It does give you license to complain to Codeweavers about how CrossOver works, and if you can convince them, they can work on getting Wine changed too.

The same amount as is in msconfig and Control Panel. Users should not have to dig through the registry to make known changes.

Control Panel and msconfig on Windows do not give you advanced OpenGL or DirectX settings. Depending on what video driver you have installed, you can access advanced OpenGL/DirectX/D3D settings, but it's not something provided by Microsoft.

Also note that Control Panel has a whole bunch of settings that can't be implemented in Wine, but that's a matter for another discussion.

And we have users whining about how to use the regedit.

And we ONLY care about them, right?

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".

Agreed. Would you like to fix up AppDB and remove all the .reg files and similar instructions?

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.

Along the same lines on AppDB, once the settings are fixed in Wine and the settings in winecfg are removed we'll get people complaining that the setting in winecfg doesn't exist any more, and we'll have to do a lot of cleaning out of the AppDB. I assume you're volunteering for this task?

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 argue that providing easy access to these settings is not "correct and proper". Of course, we both want word from AJ about it. I'm sure we can both go along with his decision, whether or not it matches our opinion on the issue.

If you are working with development level programs, you should expect problems.

That's where we're at. Wine is still in heavy development, hence the 1.1.x "development" branch.

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.

This would be 1.0.x "stable" branch. There are already plenty of "show-stopper" bugs like this where the solution is "upgrade to 1.1.x", like Warcraft 3 or WoW not working at all. Keep this in mind.

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.

Wine doesn't have customers. Stop treating it like a business venture.

[austin987]

On Wed, Apr 8, 2009 at 7:25 PM, man_in_shack <[email protected]> wrote:

James Mckenzie wrote:

Right now, people are going through the archives, visiting the Applications Database and breaking Wine and then blaming us, rightfully so.

You're an AppDB admin, so fix AppDB.

No, he's not, nor did he ever say he was. Get your facts right.


I asked you to provide CONCRETE examples of how changing these
settings is worse. Instead, you've chosen to attack myself, James, and
others who are in favor of this change. Your arguments lack merit,
proper grammar and explanation.

If you're only basing your information off of what you see in #winehq,
you've got a _very_ incomplete picture.

Now please, instead of misquoting and using 'blah blah blah' as a
summary of points, get some _actual evidence_ and show why I'm wrong.
Until then, please quit acting like you're in junior high, take a deep
breath, and go back to helping in #winehq where your attitude may be
appreciated.

--
-Austin

[man_in_shack]

On Wed, Apr 8, 2009 at 7:25 PM, man_in_shack <[email protected]> wrote:

James Mckenzie wrote:

Right now, people are going through the archives, visiting the Applications Database and breaking Wine and then blaming us, rightfully so.

You're an AppDB admin, so fix AppDB.

No, he's not, nor did he ever say he was. Get your facts right.

You're right, sorry. I apologise for confusing you with him.

Blah blah blah

I've made my opinion clear. So have you. We're not getting anywhere. This needs to be addressed by someone with the power/responsibility of committing or rejecting this patchset and/or idea.

[perryh]

Austin English <[email protected]> wrote:

There was no reason to misquote me or make me appear
ignorant by changing my statements to blah blah blah.

Actually, there was a reason: it was his way of admitting
that he had run out of rational arguments. Maybe he will
stay in his shack for a while now.

[man_in_shack]

Austin English <[email protected]> wrote:

There was no reason to misquote me or make me appear
ignorant by changing my statements to blah blah blah.

Actually, there was a reason: it was his way of admitting
that he had run out of rational arguments. Maybe he will
stay in his shack for a while now.

Sorry, I gave up trying when I realised no one here actually gives a stuff about "improving Wine". Everyone involved in the discussion, myself included, has their own opinion and we're all too charged and polarised to make any progress. At least I can take a step back from the brawl and say we're *all* at fault here, instead of the "I'm right, you're wrong, and there is absolutely no other way about it" attitude Austin and James have.

Let's see Warren's proposed patches go through the proper/official patch review system, and see what comments arise out of that. Until then, I suggest all of us charged, polarised arguers use our energy on something more productive.

[fcmartins]

Could you be more clear please?

Let me try: option 1 is not about wineprefixes, it's a a mid-way solution between keeping a wineprefix per application and having one wine prefix for all applications (as done by bare Winecfg). So:
- just take the set of settings managed by winecfg (a subset of the whole registry, right?),
- winecfg UI allows the user to specify that the current settings are specific to a certain app (identified by path name),
- keep these settings in the registry (.../wine/winecfg/app1/...)
- at launch time, the launcher checks whether the app has a specific set of winecfg settings, if so, changes the corresponding parts of the registry, and only then launches the app.
[/list]

[man_in_shack]

Let me try: option 1 is not about wineprefixes, it's a a mid-way solution between keeping a wineprefix per application and having one wine prefix for all applications (as done by bare Winecfg). So:
- just take the set of settings managed by winecfg (a subset of the whole registry, right?),
- winecfg UI allows the user to specify that the current settings are specific to a certain app (identified by path name),
- keep these settings in the registry (.../wine/winecfg/app1/...)
- at launch time, the launcher checks whether the app has a specific set of winecfg settings, if so, changes the corresponding parts of the registry, and only then launches the app.

Wine already has per-application settings for stuff configurable in winecfg and UsefulRegistryKeys. Why do you suggest a copy of the complete registry for each application?

[Warren Dumortier]

2009/4/9 man_in_shack <[email protected]>:

fcmartins wrote:

Let me try: option 1 is not about wineprefixes, it's a a mid-way solution between keeping a wineprefix per application and having one wine prefix for all applications (as done by bare Winecfg). So:
- just take the set of settings managed by winecfg (a subset of the whole registry, right?),
- winecfg UI allows the user to specify that the current settings are specific to a certain app (identified by path name),
- keep these settings in the registry (.../wine/winecfg/app1/...)
- at launch time, the launcher checks whether the app has a specific set of winecfg settings, if so, changes the corresponding parts of the registry, and only then launches the app.

Wine already has per-application settings for stuff configurable in winecfg and UsefulRegistryKeys. Why do you suggest a copy of the complete registry for each application?

I just wanted to respond to something you said earlier...
Wine does not work very well with all games and by changing the
rendering mode for example, you can speed up games by more than 100%
in some cases, like CoD4, 15FPS with default rendering, but 65FPS with
FBO!?!?

And users that will break Wine by changing those setting (may not
happen a lot...) will presume it is caused by the changed settings and
will be able to reset.

BTW, i sent the patch for testing...

[austin987]

On Thu, Apr 9, 2009 at 1:52 AM, fcmartins <[email protected]> wrote:

austin987 wrote:

Could you be more clear please?

Let me try: option 1 is not about wineprefixes, it's a a mid-way solution between keeping a wineprefix per application and having one wine prefix for all applications (as done by bare Winecfg). So:
- just take the set of settings managed by winecfg (a subset of the whole registry, right?),
- winecfg UI allows the user to specify that the current settings are specific to a certain app (identified by path name),
- keep these settings in the registry (.../wine/winecfg/app1/...)
- at launch time, the launcher checks whether the app has a specific set of winecfg settings, if so, changes the corresponding parts of the registry, and only then launches the app.
[/list]

You can do that already for most settings. In the first tab, choose
"add application", then change the settings for that app. The settings
for that app are preferred to global settings.

--
-Austin

[fcmartins]

Wine already has per-application settings for stuff configurable in winecfg.

Indeed! It was in front of my eyes all the time and I had just become blind to it! (by rushing routinely to drives and graphics).

Does it work well with the library overrides?

[austin987]

On Thu, Apr 9, 2009 at 11:29 AM, fcmartins <[email protected]> wrote:

man_in_shack wrote:

Wine already has per-application settings for stuff configurable in winecfg.

Indeed! It was in front of my eyes all the time and I had just become blind to it! (by rushing routinely to drives and graphics).

Does it work well with the library overrides?

DLL overrides/windows version/virtual desktop settings, yes.

Sound settings, no.

The rest, I'm not sure of off hand.

--
-Austin