Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Dec 1997 16:48:26 -0800
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Peter Hawkins <peter@rhiannon.clari.net.au>
Cc:        freebsd-hackers@FreeBSD.ORG, danny@hilink.com.au, j@uriah.heep.sax.de
Subject:   Re: GUI wizard interface 
Message-ID:  <28170.881023706@time.cdrom.com>
In-Reply-To: Your message of "Tue, 02 Dec 1997 10:17:43 %2B1100." <199712012317.KAA13463@rhiannon.clari.net.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
> I have almost finished writing the first release of a new library intended
> to make it very easy to put a graphical front end on wizards and managemant
> tools. Basically all you need to do is write your back end, then define
> a finite state machine to interface it. The latter is a 5 minute job.

Hmmm.  This sounds very promising, though without a bit more detail
it's hard for me comment any more significantly on it.  Strangely
enough, I've also been working on a "wizard" tool these last couple of
days since I managed to hand Mike Smith my package & installer hat a
few weeks back and am now free to think about different problems in
that same general region of the system.  Perhaps we can work together
on some aspect of this?

What I've been working up, essentially, is something which views the
problem of doing configuration as defining a set of "contexts", each
context being free to either change the context to something else or
push a new context onto the context stack, thus deferring the
operation until the current context returns and the stack is popped.
I've found that by giving each context the ability to paint the screen
with various UI objects, bind keys to actions or invoke shell
functions and certain system calls, I can pretty much represent all of
the ppp configuration screens (which I'm using as a sample problem) in
a way that's pretty obvious and, as each context is "closed" I also
get reasonable `batched commit' behavior so that things aren't altered
until the operation is truly complete.

It's basically not much different than the forms paradigm of old,
where you could enter a form as a "context" of sorts and potentially
enter other sub-forms based on what you did in various fields there.
I've just come up with a concise way of representing this which makes
sense to me (and may not to anyone else :).

I've also written it to deal with the UI objects as fairly abstract
objects, so something other than the libdialog calls which I'm
using for test purposes could be easily plugged in at some point.

How far are you from releasing an ALPHA version?  I didn't see any
URLs in your message. :)

					Jordan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28170.881023706>