Skip to Content.
Sympa Menu

sm-users - Re: [SM-Users] menuconfig for casts

sm-users AT lists.ibiblio.org

Subject: Sourcemage Users List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-users AT lists.ibiblio.org
  • Subject: Re: [SM-Users] menuconfig for casts
  • Date: Fri, 16 Dec 2005 15:15:39 +0100

Hi!

Am Wed, 14 Dec 2005 13:52:06 -0800
schrieb Andrew <afrayedknot AT thefrayedknot.armory.com>:

>
> On Wed, Dec 14, 2005 at 09:23:39PM +0100, Thomas Orgis wrote:
> >
> > 1. You get asked many questions in a linear way. Your answers are final
> > (so it looks to me). What to do when in a cast with several spells you
> > type accidentally "y" where you wanted to type "n"? Abort and redo all
> > answers that have been answered already?
>
> Actually, it remembers the answers you just gave so you dont really have
> to think about them again.
>

But still I have to watch out for the question I want to answer differently
(pressed enter one time too much: redo it again)... and there are these
answers that are remembered in a way that I cannot change them (question and
answer appearing in []brackets without a prompt) - The rule behind them is
not so clear to me. Of course, I could look at the code to find it...

> I'll point out that backing up after you answer a question isnt really
> a trivial thing to do in a robust and efficient way. Theres a lot more

I didn't say that it is trivial... just that it seems desirable for
error-prone humans;-)

> going on then whats just presented to the end user. All relavent spell
> files are shell scripts in a turing complete language, theres not really

Wait. Yes, I already noted that spells consist of shell scripts... but are
they really allowed to do everything? Could a spell config script do `rm -f
/boot/*` ? I'd think that spell scripts (apart from install) should only (be
able to) access system information in a read-only way and store their
config/do their compilation in a confined place. And besides what is allowed
for them to do, what is possible in reality? Can one guarantee a certain set
of commands to be available to the scripts (sed, perl, ...) even on a very,
very minimal system? How far does the turing completeness go in reality?

> any way to predict what they'll do without doing it or jump back in the
> middle again.

Ok, but - for a start - what's with not jumping back in the middle but just
have a hot-key to restart CONFIGURE for the current spell in a multi-spell
cast? It should be possible to restore the state the spell's CONFIGURE
started in; unless the script created - or worse: modified - some random
files in the system... I think spells should be at most allowed to write to a
temporary directory (subdir of cast/xxxx ?) and the unpacked source
directory, of course. At the final install stage, there are some files in the
system to be modified, of course... but everything before that shouldn't have
any reason (and possibly possibility) to do that.


> [much more about problem complexity, dynamic structure, weird places...]

OK, you have quite some points there... I still think that in principle the
configuration could be done in a menuconfig-like way (on the look-and-feel
side, not internally) for a whole cast together, but I see that the spell
design would have to take care of being able to go back and forth, support
enabling and disabling of things. So even if this could be done, it won't be
done in the near future.

What I think is possible, then, is to drop the whole-cast approach and to
provide sorcery functions for the spells that do what some spells (glibc with
locales) do now with self-coded dialog scripting, I guess. Extending the API
so that spells can easily let their configuratuion step appear as (nested)
menus.

Instead of

config_query VAR "Question?" y

for every option, I'd like to specify the list of options/questions somehow
(with some means to indicate relationships between options) and execute

config_menu

to get my variables set by the user working in a menu. I have to think a bit
about the DEPENDS file since I'd like to have it integrated, too.

This approach leaves existing spells unharmed (would they get an error if
they define a config_menu function themselves?) and would give me the
non-linearity that I want for the more complex spells.

Is there opposition against that API extension (supposed that probably I'll
do the work and manage to write such a menu function / its helpers to specify
the structure)?


Thomas.




Archive powered by MHonArc 2.6.24.

Top of Page