Re: GtkAssistant API thoughts

[Carlos Garnacho <carlos_garnacho yahoo es>]

Hi!,

 --- Martyn Russell <martyn russell bt com> escribió:

> 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?

there will be too a gtk_assistant_set_current_page() for custom buttons and
things like this, but it will update the visited pages list to make the back
button work correctly, it will be good to check whether the widget is mapped
before adding the page to the list, so that people can put an initial 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).

For this kind of cases I guess that it would be nice to reset the visited 
pages list right after a GTK_ASSISTANT_PAGE_CONFIRM page, and disable the 
back button, as we've supposedly applied the previous data.

> 
> > - 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?

I think that the HIG doesn't recommend putting a help button in assistants, as
these are supposed to be self-explaining enough for not needing it... that's why
it got ditched in both implementations.

        Carlos

> 
> --
> Regards,
> Martyn
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 



		
______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es