Hi,

On Thursday 14 September 2006 18:00, Jason Harris wrote:
>> What if a KAssistantPath did not need to define the entire path from
>> start to end, but could instead "branch off" of another path at page
N,
>> and merge back at page M.

>Ok, but what are the semantics of setCurrentPath (), then? After all,
this 
>would mean you can logically be in several paths (subpaths) at once.

I agree that this proposal leads to confusion. I don't want more
complexity than necessary.

> Another reason why I'm sceptical of paths is that I have another
(uncommon) 
> use case at the back of my mind: In RKWard there are "wizards"
(currently 
> custom coded), which are generated at run-time from xml-definitions of
the 
> pages and their order. Setting pages to inappropriate is simple using
some 
> static logic. However, I don't see, how I could easiyl map this to
paths.

Although this is a very uncommon use case it shows the weakness of this
api proposal.
So after this discussion (and the discussion with Thomas Zander on IRC)
I think we should keep
the setAppropriate methods. Yet I think that there is a need for a more
sophisticated approach
to assistants, so I'm in favor of page grouping.

> I've created a very rough draft of an API for that [...]
> http://rkward.sourceforge.net/temp/KAssistantDialog.thoughts

Thank you this proposal! But I don't like this one as deriving a page
group from a page is a 
misuse of inheritance as a page group is not a special page.

Nevertheless I like the idea of page groups :-) Maybe KAssistantDialog
should contain a list of page groups...

I'll try to create an improved proposal tommorow. If you have special
interest in this class, maybe we could
talk about our ideas in detail on IRC.

Best regards
Matthias