Re: gnome guru





Begin forwarded message:

>Date: Tue, 10 Nov 1998 11:30:25 -0600 (CST)
>From: Havoc Pennington <rhpennin@midway.uchicago.edu>
>Subject: Re: gnome guru
>
>On Tue, 10 Nov 1998, Jeff Garzik wrote:
>> Thinking about Gnome Guru, there is going to be a need for more dynamic
>> control over the concept of "next page" and "previous page".  The
>> sequence of questions in a wizard is often determined by user input on
>> an earlier page, and adding a pre-determined set of pages may not always
>> fit the bill.
>>
>> Can I perhaps connect to the clicked event of next and previous buttons, and
>> build my own dialog pages on the fly?
>>
>
>Feel free to fix up Gnome Guru, I was hoping someone would enhance it a
>bit.
>
>I guess a nice way to do pages would be:
>
>GtkWidget* (*GnomeGuruNextPageFunc) (gpointer data);
>
>gnome_guru_set_next_page_func(GnomeGuru*, GnomeGuruNextPageFunc);
>
>or something like that, the user function would return the proper page
>when called. I'd like to have this in addition to the current simple API.
>(if the NextPageFunc is NULL, it just traverses the list of pages
>instead.)  Then you can keep it simple if all you want is a series of
>steps, but you can also get more complicated.
>
>Other ideas for how to implement this?
>
>Havoc

In my expierence working with "wizard-like" things, there are usually things  
like OnSetActive() and OnKillActive() so verification of data can be done by  
each "page".  It would probably make sense to do something similar with the  
guru widget.  Also, another way to accomplish this is is to include a similar  
mechanism to OnWizardNext()/OnWizardBack() which actually return some  
indication of the next page to be displayed.  In the case of the guru, they  
could be pointers.  The way the OnWizard*() methods work is if you don't  
return anything special, it traverses the page list as it is, but if you  
return something "special", that page is displayed instead.  Doing it this  
way keeps things nice and encapsulated on a per-page basis and then the  
container for the pages doesn't have to do anything except maintain any data  
which should be available to all the pages.  This approach will give you both  
initialization/validation with the OnSetActive()/OnKillActive() as well as  
user-defined list traversal through the OnWizard*() methods.  Obviously, the  
concept is what's important rather than the names. :)

ast



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]