On Wed, 18 Apr 2001, John Levon wrote:
> On Tue, 17 Apr 2001, Allan Rae wrote:
[...]
> > Gotta put all those configuration items somewhere the screen isn't big
> > enough for one dialog and having multiple dialogs that you blaze a trail
> > through like W2k networking config is a bigger pain than tabs IMO.
>
> If that's a wizard, then wizards are *great* ideas, given one BIG proviso -
> each step MUST be sequential. I'm not familiar with the networking config but
> it sounds very wrong.
No it isn't a wizard it's the W2k networking equivalent of Preferences
except they make you go through two useless dialogs before you even start
seeing configuration options. The first one being a choice of adding a
new network connection or working on an existing one followed by the
option to disable or configure the existing one -- these should be
combined --- but hey this is a LyX mailing list not a W2k developers
forum.
> A (good) alternative to tabbed dialogs for very busy dialogs like preferences
> is the split pane approach used by KDE and Gnome configs. The left hand side
> can be either icons+names or a treelist. This partitions each screen very well.
> If its possible with xforms, it would be a great idea, perhaps if you goad me a
>little
> I might even have a go ;)
Let it be known that I love the Window Maker preferences utility. It uses
the split pane approach you describe with a button bar across the top.
A treelist is also okay -- Window Maker has the advantage that its
configuration areas transform into very pretty and informative icons. It
might take a bit of thought to get the Preferences config areas into a
graphical form. Good icons are international -- no translation involved.
[...]
> > > so it can go back to an ad-hoc per-frontend approach. That's fine by me...
> >
> > Did it ever leave there?
>
> apparently not, it seems I was misunderstanding the intention of your
> new design.
The intention is to make all your (that's a collective "your") dreams
possible -- provided you either build a state machine to match those ideas
or just exploit the group-action matching of the state machine engine --
hmm... maybe I should extract that part out as well since that'll be very
useful for other things. I've already had a brainwave of how to implement
macro-recording using some components of the engine.
Allan. (ARRae)
