PageStack and StackView

[Marco Martin]

On Monday 24 November 2014, Kai Uwe Broulik wrote:
> Hi again,
> 
> I was looking into porting PlasmaComponents.PageStack to
> QtQuick.Controls.StackView. PageStack provides quite some legacy features
> Marco told me weren't that important but it also has a lot of similar-but-
> different API with JavaScript functions taking a couple of parameters
> whereas Qt takes one JS Object and I think we cannot overload them (ie.
> have a method foo(bar, baz) call a foo(bla) instead.
> 
> API differences (PageStack → StackView)
> depth → depth (identical)
> currentPage → currentItem (could be alias'd)
> toolBar → for some magic toolbar thing, allegedly used in the widget
> gallery animate → there's an "immediate" property for pushing/popping
> items, our StackViewDelegate could honor that/the duration settings
> initialPage → initialItem
> busy → busy (identical)
> push(page, properties, immediate) → push(item) as a shortcut, or
> push({item: someItem, immediate: true, properties: {foo: "bar", baz:
> "bla"} }) which cannot be (easily, if at all?) overloaded to provide
> legacy support 

Uuh, from where the latter syntax of push comes from?
I don't see any problems overloading push and pop...

> Due to the invasive API differences I was thinking of keeping the PageStack
> as is, deprecated, and add a new PlasmaComponents.StackView with all the
> new fancy QQC API.
> 
> Thoughts?

I think they can be overloaded, and I would like to have that tried to see how 
many things it breaks
I would prefer keeping a single class, every new one that gets added means 
future problems.
Actually, what I would really prefer, is (besides porting the internals of 
PageStack  to it) is to have the stackviewdelegate actually come from the 
style (so no stackview subclasses needed) that may be worth of trying a patch 
to upstream stackview

-- 
Marco Martin