Re: GtkAssistant API thoughts

[Jonathan Blandford <jrb redhat com>]

Matthias Clasen <mclasen redhat com> writes:

> Last week I looked at the different proposals for moving GnomeDruid to
> GTK+ (see bug 115348). There are 2 patches. The first one has the
> following broad characteristics:

Awesome.

> After thinking some more about the different approaches here, I think I
> want to try and merge the best aspects of both patches. 
> 
> - no page objects in the API, use child properties for title, image, etc

This is clearly a better approach.  I wish I'd had them for the original
Druid.

> - ditch the "forward" and "back" signals, and use a user-specified function 
>   to compute the next page

With a fallback to the order in which you add them, right?  Also, what
are we thinking of keying off for the user function?  An enum?  The
value of the page?  The closest API analogy I can think of is
gtk_tree_view_set_column_drag_function(), which takes the columns as
arguments.  I've found that a bit clumsy in the past, though I don't
necessarily have a better suggestion.

> - derive the assistant from  GtkWindow (I don't think the GtkDialog response
>   API is a very good match for an assistant)

Agreed.

> - use a stack of visited pages as you do to implement "back". I don't think 
>   there is a need to specify a custom back function, it should always go back 
>   to the previous page

I can think of one instance where we needed a custom back.  In RP3
(which was a modem configurator program) we had a page series that went:

[ Search for modems? ] -> [ Search progress ] -> [ Results ]
          ^-------------------------------------------/

We would probably do that better now, but just giving a data point.

> - keep the page types of the first patch
> - add a per-page boolean property "complete", which indicates whether all 
>   required fields on the page have been filled in
> 
> I think by combining the "forward" function, the page types and the "complete"
> information, we can do a very good job with flow control. E.g if all pages
> following the current page are already marked complete (because they only
> contain optional fields), we can show a "finish" button (if the sequence of
> following pages ends in a page of type "confirm", we would show a "last" button
> instead, which would jump to the confirm page).

Are you adding the concept of a 'confirm' page, or is that just the last
one?

Thanks,
-Jonathan