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.
Cheers
Frederik
On 16. okt. 2011, at 14.53, ext jens.bache-w...@nokia.com wrote:
> Moving this thread to the mailing list as others might have opinions on the
> API.
>
>>> I like using attached properties for size hints as it truly solve the API
>>> issues with components not inheriting these. I would eventually like to see
>>> this in the Splitter implementation as well.
>>
>> Yes, that became an elegant solution in the end. I was in doubt if
>> this support should be provided by QtQuick2. I think a similar
>> approach could be used to set screen minsize/maxsize/orientation
>> changes in the root element. Also, maybe shortcuts could be handled
>> that way?
>
>
> I just refactored the Splitters so that they also use attached properties
> instead of explicit SplitterItems:
>
> So instead of:
>
> SplitterRow {
> SplitterItem {
> minimumSize: 200
> maximumSize: 400
> Item { }
> }
> SplitterItem {
> expanding: true
> Item { }
> }
> }
>
> We now have:
>
> SplitterRow {
> Item {
> Splitter.minimumSize: 200
> Splitter.maximumSize: 400
> }
> Item {
> Splitter.expanding: true
> }
> }
>
> I think that is a pretty nice improvement. Now I wonder if it would make
> sense to do this for TabFrame as well. But I kind of like explicitly creating
> Tabs in the TabFrame. Ie:
>
> TabFrame {
> Tab {
> title: "Tab 1"
> Item { anchors.fill : parent }
> }
> }
>
> Could become:
>
> TabFrame {
> Item {
> Tab.title: "Tab 1"
> anchors.fill : parent
> }
> }
>
> Any opinions on what would be the best approach ? I am leaning on keeping the
> Tabs explicit. Might seem inconsistent though.
>
> Regards,
> Jens Bache-Wiig
> _______________________________________________
> Qt-components mailing list
> Qt-components@qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-components
_______________________________________________
Qt-components mailing list
Qt-components@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-components
