Re: GtkAssistant API thoughts



On Thu, 2005-09-08 at 09:08 -0400, Tristan Van Berkom wrote:
> Damon Chaplin wrote:
> [...]
> >>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).
> > 
> > 
> > Have you thought through how it works in a GUI builder?
> > 
> > The "user-specified function" thing looks problematic. Signals work
> > better with a GUI builder (especially when a code editor is available -
> > you just click on the '...' button beside the signal and add the code).
> 
> Motion seconded,
>      it could easily have a RUN_LAST default method in place that
> simply changes the page & a boolean "handled" accumulator to ensure
> that only one handler turns the page.
> 
> Maybe I'm missing something, is there a reason why we'd want to
> enforce that the user supply a "forward" / "backward" handler ?
> 

It is not enforced. The default handling (move to the next visible page
in the sequence) will work fine for most situation. I think a forward
function will only be necessary for nonlinear situations.

I understand that a user-specified function is a bit problematic for
a gui builder, but without the page objects, there will not be 
per-page "forward" and "back" signals anyway, at most it would be 
a forward signal on the assistant object, taking the current page or
page number as an argument. The main reason why I think a callback
function might be more convenient than a signal is that the assistant
code may want to call it repeatedly to determine the complete sequence
of "future" pages from the current page on (e.g. to determine whether
we should display a "Last" or "Finish" button). Maybe that is
possible with a signal as well...

Matthias






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