On Sun, Oct 16, 2011 at 6:35 PM, <frederik.gladh...@nokia.com> wrote: > Hi Jens, > > I am actually not sure, if I think of the attached properties as improvement > in the case of Splitter. > After you convinced me that it's nice to have the items inside explicitly... > Attached properties are somewhat hidden, whereas the SplitterItem makes it > clear what you are dealing with and which properties it has. > I don't see any advantage in not having it explicit. Usually you will set the > min/max/default size I expect. From that point on you need to access the > attached property anyway.
I think the SplitterItem approach is a bit confusing, since it's not so aligned with QtQuick. IMO, the major downside is that the Splitter component just works (completely) with a specific element, while the rest of the QML components accepts any kind of element as child/delegate; You cannot decouple Splitter from SplitterItem, without losing some capabilities, and this dependency wouldn't be clear just looking at the Splitter API, probably one would need to see an example to notice that. The source code would be also more nested and verbose, increasing the elements tree and the cost of resize operations (wrapper + nested item recalculations). This approach also makes it harder to add custom items dynamically, since you need to wrap the item before inserting. The attached property, on the other hand, is more aligned with some important QML components like ListView (ex.: ListView.section) and can be provided in a clearer manner in the docs. I didn't look the Splitter code deeply, so I may be wrong in some assumptions. Feel free to correct me. Cheers, Adriano _______________________________________________ Qt-components mailing list Qt-components@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt-components
