[Interest] Awkwardness of delegates in heterogenous ListViews

Elvis Stansvik elvstone at gmail.com
Thu Jun 9 08:20:17 CEST 2016


2016-06-09 7:54 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
> 2016-06-08 23:59 GMT+02:00 Jason H <jhihn at gmx.com>:
>> I'm coming into this late, but can't you just set up:
>>
>> Item { // delegate
>>
>>   Item {
>>     id: view1
>>      visible: some_data_item_property == true
>>   }
>>   Item {
>>     id: view2
>>     visible: !view1.visible
>>   }
>> }
>>
>> Then make view1 and view2 your different delegates? You're just going after
>> two diferent views, right?
>
> Well it's ~5, but indeed that seems to work great! A little test:
>
>
> import QtQuick 2.4
> import QtQuick.Window 2.2
>
> import "."
>
> Window {
>     title: "Test"
>     width: 600
>     height: 900
>     visible: true
>
>     ListModel {
>         id: listModel
>         dynamicRoles: true
>         Component.onCompleted: {
>             append({
>                 "type": "color",
>                 "name": "foo",
>                 "value": "red"
>             });
>             append({
>                 "type": "flag",
>                 "name": "bar",
>                 "value": false
>             });
>             append({
>                 "type": "choice",
>                 "name": "bar",
>                 "value": "Foo",
>                 "choices": ["Foo", "Bar"]
>             });
>         }
>     }
>
>     ListView {
>         anchors.fill: parent
>
>         model: listModel
>         delegate: Rectangle {
>             implicitHeight: {
>                 if (type === "color")
>                     return colorDelegate.implicitHeight
>                 if (type === "flag")
>                     return flagDelegate.implicitHeight
>                 if (type === "choice")
>                     return choiceDelegate.implicitHeight
>             }
>             Text {
>                 id: colorDelegate
>                 text: value + " (color)"
>                 visible: type === "color"
>             }
>             Text {
>                 id: flagDelegate
>                 text: value + " (flag)"
>                 visible: type === "flag"
>             }
>             Text {
>                 id: choiceDelegate
>                 text: value + " (choice)"
>                 visible: type === "choice"
>             }
>         }
>     }
> }
>

It does not really solve the "problem" though. Say one of my delegates
is a ColorDelegate for when the item represents a color, and I want to
provide editing (my model has a setColor(index, color)).

I will then have to use parent.ListView.view.model.setColor(index,
color), thereby tying the color delegate to this way of working: It
can't be reused in another context where I have a model known to
consist of only colors (well not without artificially nesting it
inside something else, like an invisible Rectangle, so that the
reference to setColor works).

On the C++ side, it's a bit easier to make delegates that are reusable
in these two situations, since you work with createEditor and friends
instead.

Elvis

>
> I wonder why I haven't seen this approach before while searching around.
>
> Elvis
>
>>
>> Sent: Wednesday, June 08, 2016 at 11:49 AM
>> From: "Elvis Stansvik" <elvstone at gmail.com>
>> To: "Kristoffersen, Even (NO14)" <Even.Kristoffersen at honeywell.com>,
>> "interest at qt-project.org Interest" <interest at qt-project.org>
>>
>> Subject: Re: [Interest] Awkwardness of delegates in heterogenous ListViews
>>
>> 2016-06-08 15:41 GMT+02:00 Kristoffersen, Even (NO14)
>> <Even.Kristoffersen at honeywell.com>:
>>> Have you tried something like this in the delegate?
>>>
>>> property alias some_descriptive_name: parent
>>
>> It seems it's not allowed to use parent as the target of an alias (?):
>>
>> file:///home/estan/qte/qte/qml/ItemDelegate.qml:5 Invalid alias reference.
>> Unable to find id "parent"
>>
>> And this would still tie my "subdelegates" to this structure. They could not
>> be reused in other places, where lists are homogenous and I'm not using the
>> Loader approach.
>>
>> But I guess there's really no way to make a delegate that can be used in
>> both the "normal" situation and in the indirect-through-Loader approach.
>>
>> Elvis
>>
>>>
>>> (Not tested, just an idea)
>>>
>>> -Even
>>>
>>> -----Original Message-----
>>> From: Interest
>>> [mailto:interest-bounces+even.kristoffersen=honeywell.com at qt-project.org] On
>>> Behalf Of Elvis Stansvik
>>> Sent: 8. juni 2016 15:34
>>> To: interest at qt-project.org Interest <interest at qt-project.org>
>>> Subject: Re: [Interest] Awkwardness of delegates in heterogenous ListViews
>>>
>>> 2016-06-08 15:32 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>>>> Hi all,
>>>>
>>>> I'm currently using a "type" role in my items and then a Loader as
>>>> delegate, to give a level of indirection and let me choose the actual
>>>> delegate based on the "type" of the item.
>>>>
>>>> This explains it better (from my ListView):
>>>>
>>>> delegate: Loader {
>>>> sourceComponent: {
>>>> switch (type) {
>>>> case "color":
>>>> return colorDelegate
>>>> case "flag":
>>>> return flagDelegate
>>>> ...
>>>> }
>>>> }
>>>>
>>>> Component {
>>>> id: colorDelegate
>>>>
>>>> ColorDelegate { }
>>>> }
>>>>
>>>> Component {
>>>> id: flagDelegate
>>>>
>>>> FlagDelegate { }
>>>> }
>>>>
>>>> ...
>>>> }
>>>>
>>>> What I don't like with this approach is that inside my delegates, e.g.
>>>> ColorDelegate.qml, I have to use parent.ListView.view.model to get a
>>>
>>> I should clarify: I have to use this notation since it is the parent (the
>>> Loader) which is the real delegate and has the ListView attached properties.
>>>
>>> Elvis
>>>
>>>> reference to the model (needed for editing operations). The use of
>>>> "parent" here assumes a certain layout, but I see no other way :(
>>>>
>>>> How have others solved the issue of delegates for heterogenous lists?
>>>>
>>>> Best regards,
>>>> Elvis
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>> _______________________________________________ Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest



More information about the Interest mailing list