> > alias demo-in-studentpool "(multi:(X:std1:0):(X:std2:0):(X:std3:0):...)"
> Do we nest? e.g.
> alias fullx "(X:-inroot)"
> alias demo-in-studentpool "(multi:(fullx:std1:0):(fullx:std2:0))"
I'd say yes. My current idea was to just copy the given string to a
statically sized array of reasonable length (say 16k) and then recursively
expand macros there. If it exceeds size, just fail, telling the user of a
possible configuration loop.
> Also, how do we behave if we have the above and GGI_DISPLAY=fullx:-nocursor
Well - I'd suggest to just do string replacement, as this is easy to
understand for the user.
> Hmm. I don't know how the code is written now re: parsing, but if it's
> just as easy, I would think that this would look more organized:
> display-x /lib/ggi/X.so
> display-x defenv GGI_DISPLAY=640x480
> display-fullx alias "(X:-inroot)"
> display-fullx setenv GGI_DISPLAY=1024x768
> display-fullx defenv GGI_INPUT=input-linux-evdev
Right. Hmm - just thinking about what happens in the above case, then ...
Settng Env while expanding would yield the last expansion stage for
overrides and the first for defaults ... might be confusing ... hmmm - but
makes sense ...
> (and the smaller keywords help keep the formatting under control.)
Yes. Agree.
> This also would allow us to clean out the peices of code we
> have in the targets with hard-coded default values (which perhaps
> I am the only one irritated by, but...) since we could preserve
> the current behavior by installing those values in the config file.
*nod*
> (IMHO GGI_AUTO should always maximize the visible and set virt == visible,
> not decide invisibly to the user that some targets have a default mode.)
Yep. X is a particularly nasty case, where you often _want_ that it doesn't
end up hogging the whole screen, but OTOH it is not consistent with the
other targets ...
> Yes, let's write this particular portion of the code with scrutiny :).
*g* Yeah ...
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
