wine users - Apr 2009 - How can we improve WNE?

Hello everybody.

I'm a (quite) happy WINE user, but i would like to propose some things to
the WINE developers.

Something important imo, is that it must be easy to use for the user, and
some things could be better, here are some ideas to improve it by using
Winecfg:

1. Add an option to disable/enable/edit debug channels for all programs. As
you may know, a lot of programs runs faster (especially games, can be +40%
faster), so having an easy way to do this thourgh Winecfg would be a nice
idea.

2. Be able to configure some registry kets through Winecfg, especially
OffscreenRenderingMode, UseGLSL and VideoMemorySize, why not put a button in
the Graphics tab that would show up an "Advanced condifuration"
window?

3. When a program crashes, show up a window with the debugging information,
so you shouldn't always run the program in terminal. And if debugging is
disabled, say to the user it crashed, but he/she needs to enable debugging.

4. Optional imo and not very important imo: add some color schemes in
Winecfg, not themes, but some color variations. But that's really not needed
in my opinion.

I know a lot of people will respond and critic what i propose, but i really
think those little improvements (not really hard to code i presume?) could
make WINE better for users...

Please read this as an user point of view...

Thanks, kind regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.winehq.org/pipermail/wine-users/attachments/20090403/10942ba6/attachment.htm>

On Fri, Apr 3, 2009 at 9:59 AM, Warren Dumortier <nwarrenfl at gmail.com>
wrote:
> Hello everybody.
>
> I'm a (quite) happy WINE user, but i would like to propose some things
to
> the WINE developers.
>
> Something important imo, is that it must be easy to use for the user, and
> some things could be better, here are some ideas to improve it by using
> Winecfg:
>
> 1. Add an option to disable/enable/edit debug channels for all programs. As
> you may know, a lot of programs runs faster (especially games, can be +40%
> faster), so having an easy way to do this thourgh Winecfg would be a nice
> idea.
Not a bad idea. The only problem is that if we then need debugging
information, it's all gone. I think a better solution would be to add
"WINEDEBUG=-all" when ran from a .desktop and not from terminal.
> 2. Be able to configure some registry kets through Winecfg, especially
> OffscreenRenderingMode, UseGLSL and VideoMemorySize, why not put a button
in
> the Graphics tab that would show up an "Advanced condifuration"
window?
I filed a bug for this, and started on making one, but it's a bit hard
to edit .rc files if you don't have visual studio...See
http://bugs.winehq.org/show_bug.cgi?id=14776.
> 3. When a program crashes, show up a window with the debugging information,
> so you shouldn't always run the program in terminal. And if debugging
is
> disabled, say to the user it crashed, but he/she needs to enable debugging.
This has been proposed a few times before, mostly a Dr. Watson type
debugger. A simple window to tell the user the program crashed,
however, doesn't sound as familiar. I don't think, however, you'd
find
much support for it, and hardly anyone would want to spend time coding
it. If you've got a patch, however, the odds are improved.
> 4. Optional imo and not very important imo: add some color schemes in
> Winecfg, not themes, but some color variations. But that's really not
needed
> in my opinion.
That's been discussed, as the job of the distro to provide some
default matching schemes.

-- 
-Austin

Austin English <austinenglish at gmail.com> wrote on April
3rd:
>
>On Fri, Apr 3, 2009 at 9:59 AM, Warren Dumortier <nwarrenfl at
gmail.com> wrote:
>> Hello everybody.
>>
>> I'm a (quite) happy WINE user, but i would like to propose some
things to
>> the WINE developers.
>>
>> 4. Optional imo and not very important imo: add some color schemes in
>> Winecfg, not themes, but some color variations. But that's really
not needed
>> in my opinion.
>
>That's been discussed, as the job of the distro to provide some
>default matching schemes.
It is time to remind folks that Wine is used on more than Linux.  For instance,
it would be real nice to have a color scheme that matches that of the MacOSX
Aqua interface and that this color scheme be selectiable.  This may already be
available as I am not up to date on the progress of the theming project.

James McKenzie

Warren Dumortier wrote:
> 
> Please read this as an user point of view...
> 

I also would like to see those improvements. I posted some other remarks on a
related thread before seeing this one.

On Fri, Apr 3, 2009 at 9:59 AM, Warren Dumortier <nwarrenfl at gmail.com>
wrote:
> 1. Add an option to disable/enable/edit debug channels for all programs. As
> you may know, a lot of programs runs faster (especially games, can be +40%
> faster), so having an easy way to do this thourgh Winecfg would be a nice
> idea.
I've sent a patch to disable output for .desktop shortcuts, where the
output is never seen anyway. If you're running apps from a terminal,
or don't want to wait for the patch/it's rejected, just add:
export WINEDEBUG="-all" to your .bashrc/.cshrc/shell configuation
file.

--
-Austin

Just some short answers to your first two questions.
1) Debug messages can be compiled out if you want using a configure script
option.
2) We explicitly don't have the d3d options you mentioned in winecfg as we
want to get rid of the options or discourage users to use them as you need to
know what you are doing. We want to default to FBOs (OffscreenRenderingMethod)
once some remaining issues are gone, we also like to get rid of
RenderTargetLockMode, we want to autodetect the amount of videoram and so on.

Roderick

We are getting closer and closer to get rid of these options. A lot of guides
tell people to use them (sure FBOs need to be set most of the time) but most of
the others are barely needed and can make things a lot of worse. They should be
used with great care and it aren't just options to tweak performance or so
which users expect.

Warren Dumortier wrote:
> Tried to make a patch, but i have some questions.
> 
> Actually Wine compiles, but gui items are not created in the rc files,
where
> are tey exactly created? Sorry, find it strange...

I copypasted together something some days ago and it works for me. I must warn
anyone who decides to use it I have no real idea of what I'm doing here and
if it sets your hamster on fire that's your fault.

I also suspect it will totally destroy all the localizations except the English
default but in either case it should give you an idea of how to add stuff the
way you want.

http://www.kotinet.com/jukka.tastula/winecfg-burninghamster.diff.gz

Warren Dumortier wrote:
> 1. Add an option to disable/enable/edit debug channels for all programs. As
you may know, a lot of programs runs faster (especially games, can be +40%
faster), so having an easy way to do this thourgh Winecfg would be a nice
> idea.

Hy! I think this is more a task for the package-managers: I work with wine on
debian and in the debian-package-management I can choose between a normal
package and a debugging package.
So if you take this item the wine packages will look like this:

wine
wine-dbg
wine-dev

where wine is the package without debugging-infos and wine-dbg including the
debugging code.

(OK - is not really the same but take this like an example.)

Cheers!

sotel wrote:
> Hy! I think this is more a task for the package-managers:

Yes. And I'm the guy :D


sotel wrote:
> I work with wine on debian and in the debian-package-management I can
choose between a normal package and a debugging package.
> So if you take this item the wine packages will look like this:
> wine
> wine-dbg
> wine-dev
> where wine is the package without debugging-infos and wine-dbg including
the debugging code.
> 
> (OK - is not really the same but take this like an example.)
> 
> Yours sincerely
> Joerg

To expand on what Warren said, the wine package is built with mostly default
settings, including debugging channels on. Disabling debugging channels would be
a terrible thing to do for distributed packages :)

The -dbg package includes debugging symbols, which are useful for debugging Wine
using winedbg. At the very least, when an application crashes in Wine, they tell
you what line of code it crashes in (to the best of its ability).

Also note that the wine-dbg package is separate to keep the size of the wine
package down :)

Back to Warren's winecfg discussion:
I don't think these settings should be configurable from winecfg, in
particular UseGLSL, OffscreenRenderingMode and VideoMemSize. The first two are
fast approaching the point where they don't have to be changed at all, and
VideoMemSize should NEVER be set by the user. I realise there are still cases
where changing these settings improve performance or prevent crashes, as I use
them myself, but the average user should not change them without knowing at
least a little about what they do.

UsefulRegistryKeys is enough, in my opinion, until the keys themselves get
deprecated by improved implementations in the required components.

It doesn't matter: it would be wasted effort to change winecfg to show the
options now if it's all going to be deprecated soon...

I hope the "WINEDEBUG=-all on non-terminal launch" gets through.
I'd really like that.

DaVince wrote:
> It doesn't matter: it would be wasted effort to change winecfg to show
the options now if it's all going to be deprecated soon...
> 
> I hope the "WINEDEBUG=-all on non-terminal launch" gets through.
I'd really like that. I'd also love for that patch to be expanded so a
"this app crashed" window appears if the app that was not run from a
terminal crashed.

Apart from changing the .desktop files created by Wine's desktop
integration, there is no distinction between running from TTY and not running
from TTY. isatty() could be used (a C function in the unistd library), but there
are certainly cases where this won't be reliable.

There has been talk on the wine-devel mailing list about this sort of
notification, and the chatter has been mostly against it. "Your app
crashed" isn't very useful, and providing debugging information
isn't useful for the average user. Someone suggested opening a new window
with the debugger in it if the app crashes - this would be painfully difficult.


Warren Dumortier wrote:
> Again, the user is warned!!!

The average user ignores warnings. The more invasive the warnings are (e.g. nag
boxes), the more likely it is they will just hit "OK, whatever, let me
screw my system up". In particular, those users who have switched from
Windows to *nix will see a box that says "Be careful or blah blah break
things blah blah" and just hit "OK".

Having a non-invasive warning doesn't help either, as half of the average
user won't see it, and the other half will misinterpret it. I don't know
how many times I've said "fixme is not err". We even get people
coming in to the IRC channel saying "HELP I DON'T KNOW WHAT TO DO I GET
THIS FIXME", or "Hey guys, I found a bug. I get this fixme. Where do I
report it?"

IMO, making it easy for users to screw with settings they shouldn't screw
with is counter-productive. If they *really* need to change these things, they
can use regedit. What we could use is better instructions on how to do per-app
registry settings via regedit ...

Warren Dumortier wrote:
> 
> People that do not read warning are dumbs! 
> 
Well, this is quite a over-generalization, really. Most people just want to get
on with their own business and don't want to waste time fixing the computer,
which most people perceive it should work out of the box (and run windows apps,
btw) just as most stuff one buys does. Also, most people feel insecure when it
comes to computers, especially when most error messages are actually unreadable,
when not misleading. Perfectly reasonable to ignore warnings :-)
> 
> There's only one REAL reason to not include my patch: fix Wine to not
> have to change those setting, but imo, we're far from such a Wine
> version and it should be available IMO in Winecfg. Removing it later
> will be very easy too...
As a user I agree. Just because one day it will work doesn't seem a good
excuse not to have it NOW (unless there bugs, side effects, etc). Annoyingly,
the last call is to the maintainers :-)

fcmartins wrote:
> 
> Warren Dumortier wrote:
> > 
> > There's only one REAL reason to not include my patch: fix Wine to
not
> > have to change those setting, but imo, we're far from such a Wine
> > version and it should be available IMO in Winecfg. Removing it later
> > will be very easy too...
> 
> As a user I agree. Just because one day it will work doesn't seem a
good excuse not to have it NOW (unless there bugs, side effects, etc).
Annoyingly, the last call is to the maintainers :-)

Warren: Removing it later would likely be harder than you think, especially if
there are multiple changes to winecfg between committing your changes and trying
to remove it.

fcmartins: Let's examine the bugs/side effects for a minute.
User: "MY GAME DOESN'T WORK BUT APPDB SAYS IT'S PLATINUM"
Supporter: "What version of wine?"
User: "1.1.18. AppDB says it works fine in all versions since 1.1.14,
including 1.1.18"
Supporter: "Hmm ... video driver/video card?"
... and so forth, until all standard options are exhausted, until ...
Supporter: "OK, have you changed any advanced graphics settings in
winecfg?"
User: "ALL OF THEM BECAUSE THEY'RE NEEDED FOR MY OTHER GAME"
Supporter: "Well, now you have a choice. Either have a working Wine, or
have a Wine that you can only ever play one game in. Did you read the
warning?"
User: "WINE SUCKS I'M NEVER USING IT AGAIN!"

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.

In the worst case, we'd get a set of *bug reports* where people had been
messing with the Advanced settings, and the solution is either
"CLOSED/INVALID: Hit the reset button and it will work" or
"CLOSED/INVALID: Hit the reset button and you can see why it won't work
until bug 1234 is fixed"

[/quote]

Warren Dumortier wrote:
> 
> Another problem is that Wine will attract less users if configureing
> it is difficult. It is already the case when you want to run programs,
> so we really need to improve that.

Is it really Wine's goal to deliberately attract more users? Really? This is
a free and open-source project, as opposed to Crossover Office (or even Cedega)
which would want to attract more users since it's commercial.

I always find the "THIS WILL ATTRACT FEWER NEW USERS" argument to be a
cop-out, and closer to FUD (fear/uncertainty/doubt) than an argument based on
the merits of the proposed change.


Warren Dumortier wrote:
> 
> When users have to edit keys manually and stuff like that, they do not
> really like it. People prefer using a graphical way, something that i
> understand, so we should make their life easier.

Once again, you're overgeneralising. And the way I see it, most (all?) of
the settings you're adding to winecfg should not be changed unless
you're 100% certain of what you're doing (and in that case, you can use
the registry settings. It's also a graphical way of doing it, you know!)
Making it easier means people will say "hey, maybe if I fiddle with this
button it will make things shiny".

What if there was an easy, graphical way to do "sudo rm -rf /" without
asking for a password? There's nothing stopping you from doing it manually,
but if you do it manually you *have* to think about it a bit more.


Warren Dumortier wrote:
> 
> Also explaining things on AppDB for example would be easier than to
> explain how to set those keys. It's like users would add dll overrides
> in command-line, everybody prefers using Winecfg for that...

This sounds like you're trying to cater to some kind of fear of education.
"Loading regedit and putting in the registry keys manually is too
difficult!" Sorry, but that's also the way you have to do it on Windows
if you're changing stuff you're not meant to. There are ways around
this, like providing pre-written .reg files, but there are at least some cases
where this will break, and it would be difficult if not impossible to reliably
write .reg files for per-application settings.

austin987 wrote:
> On Tue, Apr 7, 2009 at 6:55 PM, man_in_shack <wineforum-user at
winehq.org> wrote:
> 
> > fcmartins: Let's examine the bugs/side effects for a minute.
> > User: "MY GAME DOESN'T WORK BUT APPDB SAYS IT'S
PLATINUM"
> > Supporter: "What version of wine?"
> > User: "1.1.18. AppDB says it works fine in all versions since
1.1.14, including 1.1.18"
> > Supporter: "Hmm ... video driver/video card?"
> > ... and so forth, until all standard options are exhausted, until ...
> > Supporter: "OK, have you changed any advanced graphics settings
in winecfg?"
> > User: "ALL OF THEM BECAUSE THEY'RE NEEDED FOR MY OTHER
GAME"
> > Supporter: "Well, now you have a choice. Either have a working
Wine, or have a Wine that you can only ever play one game in. Did you read the
warning?"
> > User: "WINE SUCKS I'M NEVER USING IT AGAIN!"
> > 
> 
> Why wouldn't they have done the same for the first application not
working?
> 

The ideas is that they've been instructed by some supporter or AppDB to use
these settings ...


austin987 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.
> > 
> 
> We _already_ allow users to break things, in much worse ways. Try
> running winecfg and setting the dpi to 480, or set ole32 to native in
> winecfg and running any builtin application.

Setting old32 to native is possible but difficult via winecfg, and I'd be
surprised if a DPI of 480 made apps crash. The point is that these advanced
graphical settings would be, at the least, difficult to support.

> 
> 
> > In the worst case, we'd get a set of *bug reports* where people
had been messing with the Advanced settings, and the solution is either
"CLOSED/INVALID: Hit the reset button and it will work" or
"CLOSED/INVALID: Hit the reset button and you can see why it won't work
until bug 1234 is fixed"
> > 
> 
> Again, we already have this happening, with users reporting bugs after
> unchecking "Allow window manager to control the windows"

Doesn't mean we want more of it happening! Some people seem to have the
mentality that if it's configurable and it breaks then it's a bug in
Wine ...

> 
> 
> > 
> > Warren Dumortier wrote:
> > 
> > > 
> > > Another problem is that Wine will attract less users if
configureing
> > > it is difficult. It is already the case when you want to run
programs,
> > > so we really need to improve that.
> > > 
> > 
> > 
> > Is it really Wine's goal to deliberately attract more users?
Really? This is a free and open-source project, as opposed to Crossover Office
(or even Cedega) which would want to attract more users since it's
commercial.
> > 
> > I always find the "THIS WILL ATTRACT FEWER NEW USERS"
argument to be a cop-out, and closer to FUD (fear/uncertainty/doubt) than an
argument based on the merits of the proposed change.
> > 
> 
> You've made the same logical flaw earlier (WINE SUCKS I'M NEVER
USING
> IT AGAIN!).

If anything, I'm trying to point out that these settings would do nothing
but defer the "WINE SUCKS" to later on.

> 
> 
> > Warren Dumortier wrote:
> > 
> > > 
> > > When users have to edit keys manually and stuff like that, they
do not
> > > really like it. People prefer using a graphical way, something
that i
> > > understand, so we should make their life easier.
> > > 
> > 
> > 
> > Once again, you're overgeneralising. And the way I see it, most
(all?) of the settings you're adding to winecfg should not be changed unless
you're 100% certain of what you're doing (and in that case, you can use
the registry settings. It's also a graphical way of doing it, you know!)
Making it easier means people will say "hey, maybe if I fiddle with this
button it will make things shiny".
> > 
> 
> We allow the same thing for DPI, which has _no_ warning. Now, it has
> the preview, but for a _long_ time that wasn't the case.

Changing the DPI is not likely to break everything. Changing these
"advanced" graphics options is.

> 
> 
> > What if there was an easy, graphical way to do "sudo rm -rf
/" without asking for a password? There's nothing stopping you from
doing it manually, but if you do it manually you *have* to think about it a bit
more.
> > 
> 
> You can easily graphically remove ~.  Just run nautilus, select all,
> and click delete.
> 
> This, however, is drastically different. Do you lose files here? No,
> your game doesn't work, but for many people it will. It's a two way
> street. No data, however, is lost, so please don't make that
> comparison.

Perhaps it was a bad example. Point is that these changes sound to me like:
"It can be done, and who cares if it breaks everything? It should be easy
to do!"

> 
> 
> > Warren Dumortier wrote:
> > 
> > > 
> > > Also explaining things on AppDB for example would be easier than
to
> > > explain how to set those keys. It's like users would add dll
overrides
> > > in command-line, everybody prefers using Winecfg for that...
> > > 
> > 
> > This sounds like you're trying to cater to some kind of fear of
education. "Loading regedit and putting in the registry keys manually is
too difficult!" Sorry, but that's also the way you have to do it on
Windows if you're changing stuff you're not meant to. There are ways
around this, like providing pre-written .reg files, but there are at least some
cases where this will break, and it would be difficult if not impossible to
reliably write .reg files for per-application settings.
> > 
> 
> Agreed on that.
> 
> -- 
> -Austin
Can we also agree that registry settings for these "advanced' graphics
settings are "good enough" for people who "need" them?

austin987 wrote:
> 
> No, sorry, disagreed there. I don't think that graphics settings are
> any more special than any other wine configuration settings.
> 

Changing VideoMemorySize does nothing but hide other bugs (which I hear are
being worked on). Changing OffscreenRenderingMode can cause a lot of problems
with a wide variety of apps, everything from "textures are broken" to
"complete crash of Wine and it took the buggy video drivers with it".

More harm than good.

Enough said (on my part).

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.

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.


austin987 wrote:
> 
> Long story short, I see a lot of hypocrisy in the argument that
> "changing graphics settings can cause crashes/bugs, we can't allow
> that" and "here, change DLL load order to native, even for native
Wine
> programs. No warning needed, you're smart enough to figure that
out."
> 

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.


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.


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.


austin987 wrote:
> then remove winecfg.

Which won't happen, because then there would be no simple way to change
things like audio drivers, reported Windows version, drive type configurations,
DPI settings (you pointed out earlier that there is a preview for the DPI
setting, can't have a preview via regedit!), shader settings, and the
"Desktop Integration" directory settings. Sure, you can change all
those via registry too (since the settings are stored in the registry) but these
are settings that are common to (virtually) every single application run in
wine. The advanced graphics settings are only required for a small handful of
games, and are more likely to cause problems than solve them.


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.


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.


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.

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

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.

austin987 wrote:
> 
> The settings are _not_ as rare as you think. Blah blah blah.
> 
> The point is that those settings are useful, blah blah blah.
> 

Yes they are and no they're not. There, answered. I win.

What part of "opinions are too polarised" did you not get?


austin987 wrote:
> 
> We still don't have sane defaults.

So submit patches to fix that!


austin987 wrote:
> 
> Blah blah blah not as quick as you think it's going to be.

Soon enough.


austin987 wrote:
> 
> Blah blah blah
> _NOT_ as deadly as you think. It doesn't lead to data loss, only
> crashes in some programs. Changing some native dlls has the same
> effect.

So make changing the DLLs to native easier too!


austin987 wrote:
> 
> Blah blah blah babysit users for everything.

How many times, we're not! They have the whole registry to screw around
with, and they have UsefulRegistryKeys to point them in the right direction.


austin987 wrote:
> 
> Blah blah blah but
> changing graphics settings is _completely_ different. It's not a
> special case, simply because it'll be fixed soon, nor because it can
> crash other applications. Blah blah blah.

When a setting is capable of crashing all but a handful of apps, I don't
want to see it easy to set.

Leave this to better people to decide. Patchset belongs on
wine-patches/wine-devel.

Blah.

man_in_shack <wineforum-user at winehq.org>
>Sent: Apr 8, 2009 9:37 AM
>To: wine-users at winehq.org
>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.[/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?
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:
>> > 
>> > > 
>> > > 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.
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.[/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.
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

James, I fully share your viewpoint, but I have to disagree with the use of the
word "idiots", or derivatives. It is incorrect and can not help Wine.I
have done quite a bit of helpdesk and learned to respect the users, which most
IT people don't. They like to call users idiots, when in fact the users
might just be ignorant in a fair way (no training, no time, no personal
interest, other priorities - do their work, enjoy the game they paid). Even
worse, often it is the fault of the IS system and it's all to easy to blame
the user.

Sorry for the preaching, I understand you are an experience professional and you
don't mean to be offensive on anyone (you are defending them), but I'm
also an experienced IT professional, and I deeply dislike the lack of
professionalism shown by this and other types of abuses of IT people on users
(often taking advantage of their technical ignorance).

fcmartins <wineforum-user at winehq.org> on April
8th:
>
>James, I fully share your viewpoint, but I have to disagree with the use of
the word "idiots", or derivatives. It is incorrect and can not help
Wine.I have done quite a bit of helpdesk and learned to respect the users, which
most IT people don't. They like to call users idiots, when in fact the users
might just be ignorant in a fair way (no training, no time, no personal
interest, other priorities - do their work, enjoy the game they paid). Even
worse, often it is the fault of the IS system and it's all to easy to blame
the user.
>
I agree with your viewpoint, but there are folks out there that would not own a
computer without the aid of Mr. Gates & company.  There are stories about
phone calls being taken where the user's monitor was not displaying and that
there was a power outage.  Fortunately, the receipiant of the call took the time
to explain why the monitor was not working and the caller accepted the
explanation.  There are users out there that have no clue what a power switch is
and what it is used for.  I've dealt with them face to face and the solution
was to hook up a power strip where they could shut everything off and turn it
all back on.  I don't put the blame on the user and I don't desire to
call them stupid.  They are not.  As an example, my first wife was very computer
illiterate and that worked to her advantage as she did not try to do things with
computers they were not designed for.  However, it took a friend of ours over
eight hours to work through one page in Word with her.  These are the folks I
refer to as ID10Ts.  There is the class of folks I call nOObs.  They are
familiar with Windows, know a little about how it works under the hood and just
need a guiding hand to get where they need to be in Wine.
>Sorry for the preaching, I understand you are an experience professional and
you don't mean to be offensive on anyone (you are defending them), but
I'm also an experienced IT professional, and I deeply dislike the lack of
professionalism shown by this and other types of abuses of IT people on users
(often taking advantage of their technical ignorance).
>
I don't try to take advantage of their ignorance.  However, there is a point
where you finish trying to drown the horse and figure that you are not going to
make it drink.  I've worked with that type of user.  You can show them the
movements of the mouse, the keys to click and they still manage to kill their
computer on a weekly basis.  Maybe they do it for fun, but it is definitely not
malicious.  Sometimes ignorance is bliss, but to some of us it is a major source
of work.  It mainly happens on a Friday afternoon, one-half hour before going
home.  These are the folks we need to KISS the system so that they will know
what they are doing is dangerous and may cause serious damage.  This is along
the lines of running Wine as root and other actions.

Also, to any user that found my descriptions offensive, they are NOT meant for
you.  If you are reading this forum/mailing list, you are much smarter then the
folks I'm talking about.  I stand ready to assist you in getting your
favorite program running with Wine, especially if you own a MacIntosh computer.

Very respectfully,

James McKenzie

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.

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


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


James Mckenzie wrote:
> 
> 
> 
> man_in_shack wrote:
> > 
> > How about keep winecfg simple? I like this idea better.
> > 
> 
> I agree,

Resolved. Argument over.


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


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


James Mckenzie wrote:
> 
> continue pissing off users

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


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


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


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


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.


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


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


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


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


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


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

> 
> 
> [quote="James Mckenzie"]
> 
> man_in_shack wrote:
> > 
> > "Real fix" is to code.[/quote
> > 
> > I agree that the proper method is to fix the code.
> 
> 
> Resolved. Argument over.
> 
> 
> James Mckenzie wrote:
> > 
> > 
> > man_in_shack wrote:
> > > 
> > > 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 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.
> 
> 
> 
> James Mckenzie wrote:
> > 
> > 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.
> 
> 
> James Mckenzie wrote:
> > 
> > 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.
> 
> 
> James Mckenzie wrote:
> > 
> > You have got to visit the unoffical Wine repositories.
> 
> 
> Which are not supported by WineHQ. Awesome argument. Well done. You win the
internet.
> 
> 
> James Mckenzie wrote:
> > 
> > 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?
> 
> 
> James Mckenzie wrote:
> > 
> > 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.
> 
> 
> James Mckenzie wrote:
> > 
> > See my comment above.  Take a look at the Ubuntu user support forum. 
It's scary how ignorant some users are.
> 
> 
> Agreed.
> 
> 
> James Mckenzie wrote:
> > 
> > 
> > man_in_shack wrote:
> > > 
> > > 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.
> 
> 
> Resolved. Argument over.
> 
> 
> James Mckenzie wrote:
> > 
> > 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.
> 
> 
> James Mckenzie wrote:
> > 
> > 
> > man_in_shack wrote:
> > > 
> > > 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.
> > 
> 
> 
> 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.
> 
> 
> James Mckenzie wrote:
> > 
> > 
> > man_in_shack wrote:
> > > 
> > > 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.
> > 
> 
> 
> 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.
> 
> 
> James Mckenzie wrote:
> > 
> > And we have users whining about how to use the regedit.
> 
> 
> And we ONLY care about them, right?
> 
> 
> James Mckenzie wrote:
> > 
> > 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?
> 
> 
> James Mckenzie wrote:
> > 
> > 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?
> 
> 
> James Mckenzie wrote:
> > 
> > 
> > man_in_shack 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 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.


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


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


James Mckenzie wrote:
> 
> 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 wrote:
> On Wed, Apr 8, 2009 at 7:25 PM, man_in_shack <wineforum-user at
winehq.org> 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.


austin987 wrote:
> 
> 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 wrote:
> Austin English <austinenglish at gmail.com> 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.

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?