On Tue, Apr 7, 2009 at 6:55 PM, man_in_shack <wineforum-user@xxxxxxxxxx> wrote: > > 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. Changes to winecfg are pretty rare, actually. > 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 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. > 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" > [/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. You've made the same logical flaw earlier (WINE SUCKS I'M NEVER USING IT AGAIN!). > 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. > 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. > 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
