Re: a Wizard/Druid/Assistant widget for gtk

[Jonathan Blandford <jrb redhat com>]

Matthias Clasen <maclas gmx de> writes:

> > 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).

"Go Back/Continue"?  I kind of like that -- though it's a bit more
verbose.  I don't like the Java assistant L&F as much.  The button
placing is funny to me.

> > This seems a little inflexible.  I've seen pages which change types
> > based upon a toggle button.  As an example, take a wizard in which you
> > have a list of items to select from.  There's a '[ ] Select custom
> > properties' button at the bottom that toggles between 'Next' and
> > 'Finish'.  This way you can either create a simple object, or set up all
> > the I can mock something up if this was unclear.  Also, some
> 
> To support changing page type on the fly, we would just need to
> hide/show the appropriate buttons in gtk_assistant_set_page_type() if
> the page being changed is the current one. I hadn't thought of this, but
> it should be easy.

Sounds good.  Also, if we make it a GtkDialog

> > dialogs like adding their own buttons.  'Help' is an obvious one, but
> > sometimes applications add other buttons.  I vaguely recall bug-buddy
> > had a 'Get Backtrace' button or something.
> > 
> 
> I decided to omit the help button which was in GnomeDruid, since the HIG
> rightly argues that you have already missed the #1 goal of a wizard if
> your wizard is complicated enough to warrant a help buttons. Neither the
> Java LAF nor the Aqua HIG mention help buttons for wizards. The Aqua HIG
> does recommend to display a progress bar for long operations in the
> button area, so there is some precedent for having some from of
> action_area.

Good point.  The Help button is wrong, but other buttons are probably
not so.  Being able to access the action area is important.  If we make
it a GtkDialog, that will give us some access.  I'm a little concerned
that the hbuttonbox isn't flexible enough, though.

> Is your proposal to reintroduce GtkAssistantPage and move the drawing
> code there ?  

I wasn't sure.  I was just concerned about exposing too much of the look
of the assistant in the API.  We probably should just keep it the way it
is, though.

> You can just return TRUE, no need to set_page() to the current page;
> set_page() to the current page won't retrigger ::prepare. Regarding the
> slow operation, I was assuming that one would do that like the Java LAF
> recommends: have a confirmation page with a finish button, followed by a
> progress page.

You don't want that in the case where you are, say scanning for modems
to put in an option menu in the next page.  It might be a slow task, but
it might not be.  In that case, you'd probably put a busy cursor up, and
popup a progress dialog after a second.

Still, I missed the return value in your proposal first time around.
That sounds fine.  It will probably cause some bugs for those who forget
to put any return at all (like event handlers currently do), but that's
life.

> > [Some comments on the API ]

Looks good.

-Jonathan