On Tue, 28 Jan 2003 11:53:10 -0800
Ian Romanick <[EMAIL PROTECTED]> wrote:
> How do we want to handle the case where a user changes video cards?
> Some of the parameters are likely to be generic, but a lot will be very
> device specific. The issue here is that the set of available parameters
> will change. A releated issue is when the set of availble parameters
> change from one driver release to another. So, do we want to key
> options on hardware device, screen (in the X sense), or something else?
> The answer to this question will likely dictate how we handle multi-head.
>
> I think we're going to end up with two keys. One is the application
> (with a default available) and the other will be something to identify
> the device and/or screen. How do we want to specify them? By this I
> mean, do we want to select the application then the screen (like you
> suggest above) or the other way around? I had been leaning towards
> screen then application. The other option, that would complicate
> processing, is for it the be free form. Have a screen tag and an
> application tag. You could have something like:
>
> <screen id="0">
> <application name="quake3.x86">
> <!-- set the prefs here. -->
> </application>
> </screen>
>
> Doing it the other way around would also be valid:
>
> <application name="quake3.x86">
> <screen id="0">
> <!-- set the prefs here. -->
> </screen>
> </application>
I like the free nesting. Though this might confuse GUI tool.
> The problem with that is that it would allow non-sensical nesting. I
> mean, what the hell does this mean?
>
> <screen id="0">
> <application name="quake3.x86">
> <screen id="2">
> <!-- set the prefs here. -->
> </screen>
> </application>
> </screen>
I think allowing arbitrary nesting order (and depth) wouldn't make
parsing any harder for the driver. While it parses the config file it
just discards all sections which don't match the current situation. Thus
in the above example it finds "I'm on screen one" first so it parses the
<screen id="0"> section further. Say quake3.x86 matches, too. Then it
finds the <screen id="2"> which doesn't match the current situation. So
all options or further nested sections contained in that section are
ignored.
> One nice side-effect of this is that it becomes very easy to move,
> delete, or import profile sections. If you want to import a set of
> application preferences for a specific screen (perhaps from a file that
> shipped with the application), you just insert its tree in the correct
> place. If you un-install an application and want to remove its profile,
> you just delete its subtree. This works with the nesting in either
> order, as far as I can tell. I'm pretty sure both expat and libxml have
> the ability to do this easilly. I don't know about libxf86cfg, could
> somebody check?
>
> Then there's the issue of how to specify the preferences. How does the
> driver communicate the set of available options to the various utilities
> (GUI or otherwise)? This issue is a bit more complicated than it seems.
> There needs to be a way to specify dependencies (i.e., this option is
> only available is some other option is set / not set). If we settle on
> a small set of option types, things are simplified a bit. I'm thinking
> something similar to the set of available form input types HTML. I
> think boolean, enum, float, and perhaps string should cover everything
> we would need. A multi-select enum might also be needed.
>
> In the config file, I think the options could be specified as simple
> name / value pairs. Something like '<option name="tcl_enabled"
> value="true"/>'. For multiselect enums, the value would be a comma
> separated list of the selected options. I don't fully understand the
> nesting in your example.
>
> As an aside, I believe that all of this so far would work with an
> XF86Config style file format as well.
In X86Config the order of nesting is fixed. As an example, "Display" is
always a SubSection of "Screen".
> Another thing to consider is internationalization. We should make it
> possible to specify different translations of text with in the driver's
> list of options. A utility could read the list of options from the
> driver and present the user's prefered langauge, if available. As we
> shift to a Joe User mindset, internationalization will become more and
> more important.
Good idea. I would not like to internationalize option names. But if
you're talking about description strings, which could be used for
tooltip-like help in the GUI, then I agree.
Felix
__\|/__ ___ ___ ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
[EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
