> What if, libggi.conf were to look something like this:
>
> display-x display/X.so DEFMODE=640x480;DISPLAY=-nocursor
> display-xlib display/Xlib.so DISPLAY=-nocursor
> display-fbdev display/fbdev.so DEFMODE=600x800
>
> The options would be overridden by the environment, but would be there
> if the environment variables were not set...
O.K. - let me take this one a step further:
I'd prefer:
alias fullx "(X:-inroot:-nocursor)"
This allows to use the feature to easily build stuff like:
alias demo-in-studentpool "(multi:(X:std1:0):(X:std2:0):(X:std3:0):...)"
While hacking that in, you might as well want to do the same for LibGII,
where it is even more useful, if you want to bind a whole bunch of
nonstandard inputs to some targets.
Now for the hard part:
How do you want to communicate options like "DEFMODE=" down to the other
subsystems that will use them ?
For simplicity I am tempted to just use two directives like this:
setenvifunset demo-in-studentpool DEFMODE="640x480"
and
overrideenv xfullscreen DEFMODE="1024x768"
The idea would be to actually manipulate the environment and use it to carry
the data. Advantage: Also works for loading inputs.
Disadvantage: lacks elegance and might be a security problem.
The latter can be easily be circumvented by always appending GGI_ before the
variables. However that's not actually necessary, as you are in security-
trouble anyway, if someone can write libggi.conf.
Thus I propose:
4 new keywords for libggi.conf
a) alias aliasname "(Display-Definition)"
Will "substitute" each occurrence of "aliasname" in a target description
string with "(Display-Definition)".
b) suggestenv aliasname VARIABLE=CONTENT
Will set VARIABLE to CONTENT, if it is unset in current environment. When
closing the display, this should be undone. When in an "unsafe" file (see
d), only accept VARIABLEs that start out with GGI_.
c) overrideenv aliasname VARIABLE=CONTENT
Will set VARIABLE to CONTENT, even if already set in current environment.
Unfortunately probably undoable. When in an "unsafe" file (see d), only
accept VARIABLEs that start out with GGI_.
d) unsafeinclude filename
Will include filename, doing a few common glob-expansions (~ in particular)
to allow for users to add their own aliases and setups. Such files would
discard library references and limit b) and c) as decribed there.
Comments welcome.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
