Re: GtkAssistant API thoughts

[Martyn Russell <martyn russell bt com>]

On Wed, 2005-09-07 at 11:29 -0400, Matthias Clasen wrote:
> 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:

This all sounds really good!

> - uses ::forward and ::back signals to let apps specify the  
>   next/previous page
> - has ::prepare signal which let apps override default navigation button
>   visibility/sensitivity
> - has a concept of page types and uses that to help setting up good
> defaults for button visibility/sensitivity
> - is just a container which needs to be stuffed in a window
> - uses a ::finish signal to signal to the app when to apply changes
> - uses ordinary widgets as pages and has child properties for per-page
>   data
> 
> The second patch 
> 
> - uses user-specified functions to determine the next/previous page

In Gossip we currently use the new account druid as the welcome druid
too, all we do is skip the first page where appropriate. I am guessing
these user functions will allow us to set the start page?

Plus, I guess it is along the same lines as specifying the a page to
show, but will the new API handle looping back to index 'n'? (I am
thinking in the case where you would add an account and then at the end
have the option to add another account).

> - is derived from GtkDialog
> - doesn't have a ::finish signal, instead uses the dialog response
>   api to signal when to apply changes
> - has a special GtkAssistantPage type, and uses ordinary properties on
>   it for per-page data
> - uses a stack of visited pages for the (default behaviour of the) back
>   button
> 
> 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
> - ditch the "forward" and "back" signals, and use a user-specified function 
>   to compute the next page
> - derive the assistant from  GtkWindow (I don't think the GtkDialog response
>   API is a very good match for an assistant)
> - 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
> - 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).

Any thoughts on a "Help" button and how that all fits in?

--
Regards,
Martyn