RE: a Wizard/Druid/Assistant widget for gtk

[Matthias Clasen <maclas gmx de>]

> > > Just to confirm, are we happy with "next" and "back" as 
> > terminology?  To
> > > me, forward/back and next/previous are logical language 
> > pairings.  It
> > > would be good to get confirmation from the UI team before 
> > writing this
> > > in an API.
> > 
> > Yes, I also thought about this inconsistency, but didn't come up with
> > something sufficently better (the Java LAF examples also use 
> > Back/Next,
> > the Aqua HIG example uses Go Back/Continue).
> 
> Would it not be logical to use the STOCK icons (forward and back)?  The
> first thing people usually focus on is the image on the button, and I
> think
> that it should really be consistant with the rest of GTK.

Thats what the code does...

> I know it is a little early to get into the look at this stage, but there
> are couple of things I have noticed which could be improved.  I am
> comparing
> this to the Inno Setup (a small image is available here:
> http://www.jrsoftware.org/isinfo.php).  
> 
> * They have two types of pages, one (as seen on the link above) has an
> image
> on the left and the welcome message on the right (this is also used in the
> closing page(s)).  The other type (of which I could not find a shot for)
> is
> simply a title for that page, plus a short description and the small icon
> and then a mid section for the controls.
> 
> * The assistant container at the bottom (with Cancel, Finish, etc buttons)
> is always shown from the left side to the right side where as the image
> you
> posted shows the EggDruid to have the left strip (in red) all the way to
> the
> bottom of the Dialog.
> 
> The Inno wizard makes use of the Top and the Left but not at the same time
> (which is what the EggDruid seems to do). - This is just a consideration.

The sidebar is optional (as you can see in the first demo of
testassistant.c), but I 
guess turning it on and off on page switch may be a bit disturbing.

> > > 
> > >  * How will control-flow work?  How would you handle 
> > hitting next and
> > >    preventing it from automagically going to the next page? 
> >  Would you
> > >    have to call set_page() to the current page?  Will that retrigger
> > >    "prepare"?  Do you stop the signal emission.  For 
> > example, consider
> > >    an app with a slow operation.  You might want to popup a dialog
> > >    "Searching for new hardware [ Cancel ]" and not actually 
> > switch pages
> > >    until that task is finished.  When they hit next, you 
> > basically want
> > >    the Assistant to do nothing.
> > 
> > You can just return TRUE, no need to set_page() to the current page;
> > set_page() to the current page won't retrigger ::prepare. 
> > 
> 
> Something which I would want to be able to do is to jump pages.  For
> example, if there is an initial page with two Toggle buttons, and the
> wizard
> takes two different paths based on that choice, how would that be done?

By connecting to ::next, jump to the appropriate page, and return TRUE to 
avoid the default handling. Simply making the pages to be skipped invisible 
should work as well.

> 
> Additional thoughts:
> 
> I have also seen wizards/assistants have a progress bar.  The programmer
> can
> by all means have their own page do this, but should an embedded progress
> bar be considered?  

What progress would that track ? The completion of the wizard ? In that
case, I think a two-pane approach with a list of steps (current step highlighted)
in the left pane like in the Java LAF makes much more sense. Progress bars
should display the completion of automated operations, not progress of the
user IMO.

Matthias

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post