On Tue, Dec 03, 2002 at 10:14:45AM -0800, Linus Torvalds wrote: | | Why? I don't understand this reluctance to just admit that the _user_ may | be right.
I note your use of the word "may." Sometimes the user can happily express a simple preference, but often such a choice has consequences that the user can't foresee, and won't like. For example, a user might say to himself "I'll choose 32bpp textures so that I can get higher-quality rendering." What he doesn't know is that 32bpp textures are so much larger that his game no longer has enough texture space available on his system. The game has to fall back to lower-resolution textures or eliminate other quality-oriented features like multitextured lightmapping. In the end, the user's ability to express a low-level preference didn't achieve what he wanted. Things get a *lot* worse when resources are explicitly shared rather than virtualized. | In short, the only sane remaining thing to do is to have environment | variables. ... There's a minor debate here about the control mechanism for expressing preferences -- GUI tool, config file, environment variables. But the main question is where the control mechanism resides. You've mentioned that libraries can't know how to resolve questions of user preference. That's true. But neither users nor libraries can know how to understand the tradeoffs associated with a particular preference. The environment is just too complicated and variable for that. There is only one system component that has enough information to "understand" high-level preferences expressed by the user, and the low-level tradeoffs that have to be made to implement those preferences. That's the application program. The app needs information about its environment and control over the functionality of the graphics subsystem to do its job. So in general it's wrong to compromise the app's ability to control the graphics hardware by overriding it at a low level. | Sure, you could say that every program should just specify the hinting | itself, but let's face it - it's inconvenient for programmers to have to | have the setup screens (_especially_ since the settings will depend on | what the card is) ... I'm all for developing tools to make it easier to express and implement user preferences... | ...but it's also supremely inconvenient for users to have | to set settings in 10 different programs in 10 different ways. ... but that's exactly what we have to do. It would be great if there were a nice way to avoid it, but there isn't. Only the apps know which settings are useful (or even possible). As you said in a subsequent paragraph: | ... different | programs almost certainly want different settings. Some games need to have | less detail to be playable, others want to be cranked up to full | settings. So it's clear that the locus of control must be in the app. | ... Arguing against them is just not very clever. As for whether the control mechanism should be environment variables, config files, or whatever: I don't have any particular objection to application-specific environment variables. But general-purpose environment variables that apply to all apps and persist for the life of a shell is bad design practice. It's guaranteed to lead to unreproducable bugs and exactly the sort of ad-hoc environment setup requirements that we have to eliminate if desktop Linux systems are to offer a good experience for end users. Allen ------------------------------------------------------- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
