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>