On Tue, 3 Dec 2002, Allen Akin wrote:
>
> No, and as I've said several times before, I don't have a major problem
> with it as long as the "knob" that controls the workaround is
> application-specific. For example, if the workaround is for Q3A and
> we're using environment variables, then the variable that controls it
> should be named "GL_Q3A_SECONDARY_COLOR_WORKAROUND", or whatever. That
> way there's no contamination of the environment for other apps when the
> workaround is enabled for Q3A.
This illustrates one of the bad points of using environment variables.
Will we have to add environment variables every time a new app is pushed
out the door? Bad approach.
> The approach I want to avoid is defining a bunch of general low-level
> switches ("What's the default texel size?" "Should the multitexturing
> extension be exposed?" "Is it OK for polygon rendering to be
> non-conformant?" "Should hints default to NICEST or FASTEST?" and so
> on, and so on, and so on. There would be hundreds.). This is not the
> way to provide effective controls to the end user, it's not the way to
> keep application behavior consistent from run to run on the same system,
> and it doesn't even help make the driver developers' lives easier.
Ah, but it *must* be defined as a bunch of low level switches to make
developers lives easier. Follow this train of thought for the momment.
I think the thing that will make users lives easier is a tool that can
modify the per-app configuration. I think it was Alan that gave a simple
example of how he thought a GUI should exist. Essentially the claim is
like you stated above that the configuration would have to be straight
forward and simple to be of use. If we can take a hint from Windows on
this we can do it in a way such a this to make it best for both worlds...
The gui tool would have two modes of operation ... basic and advanced.
The advanced would obviously let you tweak the guts of the thing. The
basic would have a higher level view that would probably have pre-defined
settings for common apps for a particular card (think fastest, highest
quality, balanced etc.) along with various "grouped" settings. The
predefined modes would appear to only operate on the "grouped" settings.
It provides a nice balance between those that can tweak things and those
that just want the basics. The duty is left up to the people doing the
GUI part of things. The core DRI team just has to worry about support the
low level config part.
--
//========================================================\\
|| D. Hageman <[EMAIL PROTECTED]> ||
\\========================================================//
-------------------------------------------------------
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
