Delegate creation and multithreaded property updating

Asperamanca

@GrecKo But I do agree that for OP's use case, the model is the better approach.

GrecKo

& 2.
I don't really understand the question. Models&Views does that.
A ListView can do that with the added benefit of delegate pooling.
If the ListView does not fit your use case (you might not need it to position the delegates). A Repeater (or Instantiator) plus a proxy model might do the trick.
This doesn't involve JS, just a couple more QML objects with basic bindings.
You still could do that in C++ if you want.

Your solution does work, I'm just saying it might not be the most straight forward one or necessary for everyone.

Asperamanca

@GrecKo said in Delegate creation and multithreaded property updating:

& 2.
I don't really understand the question. Models&Views does that.
A ListView can do that with the added benefit of delegate pooling.
If the ListView does not fit your use case (you might not need it to position the delegates). A Repeater (or Instantiator) plus a proxy model might do the trick.

Please walk me through it, if you would be so kind.
When I want to display a table of items, I use a TableView. The model can be huge, but only the delegates actually needed for display are created (and a few more to ensure smooth scrolling, maybe). So far, so good.

In my case, I do not want to arrange my components in a pre-defined way. The user has positioned them in a certain position, and maybe there is some (also user-specified) runtime logic that could move them around. Also, whether they are actually visible right now might depend on runtime logic.

A ListView is a Flickable. A flickable does not make sense for my use case (the components are geometrically unrelated to each other).

A Repeater (AFAIK) only instantiates the same type of item. I could use it, but I would need a wrapper item.
Then again "The Repeater type creates all of its delegate items when the repeater is first created.". That means, if I have 100k data classes, I will get 100k QML items of some kind. Now, I'd need to measure how expensive that would be, and it's certainly not free.

A Loader can only load a single component. I could probably pair it with Repeater to get what I want. I think it would pretty much do the same thing as my current code, at the cost of always loading the 100k Loaders. Also, how do you use a loader to load a component from a QML module directly? Eventually, I want my components to be pre-compiled.

Did I miss an option?

I admit, part of the reason I chose this approach is also that I'm not much of a ModelView guy, so I didn't consider using ModelView for anything else but where a ready-to-use View component already exists.

felsi

I don't want to bother you guys anymore, but i have some final thoughts...
Trying to avoid bindings as much as possible has become a bit of a habit and i use connections+js a lot...
It is clear now, but i did not expect, that connections+loader can have these side effects.
Maybe this is worth to be mentioned somewhere in the documentation with a small note.
And, by the way, is the following safe?

Button
{
    property PlaylistTrack playlistTrack
    onPlaylistTrackChanged: updateTrack()
    
    property Track track: playlistTrack.track
    onTrackChanged: updateTrack()
    
    function updateTrack()
    {
        ...
    }
        
}

felsi

Just a small simplification mistake, i don't call it twice, of course...

Asperamanca

@felsi Whether it's safe would mainly depend on what you do inside updateTrack() (do you check for null, etc.)
I can see no fault in calling updateTrack() in both change handlers.

GrecKo

@Asperamanca said in Delegate creation and multithreaded property updating:

In my case, I do not want to arrange my components in a pre-defined way. The user has positioned them in a certain position, and maybe there is some (also user-specified) runtime logic that could move them around. Also, whether they are actually visible right now might depend on runtime logic.

A Repeater (AFAIK) only instantiates the same type of item. I could use it, but I would need a wrapper item.
Then again "The Repeater type creates all of its delegate items when the repeater is first created.". That means, if I have 100k data classes, I will get 100k QML items of some kind. Now, I'd need to measure how expensive that would be, and it's certainly not free.

A Repeater with a DelegateChooser can handle this case. As for not creating the 100k data classes you could only expose the one you want to be instantiated in a model of your own or expose everything and have a proxy model do the work of filtering out the elements you don't want.

Asperamanca

@GrecKo I was not aware of DelegateChooser. Thanks!

felsi

Good to know, thanks!
It would require the usage of on<Signal> handlers for all properties of PlaylistTrack.
So i took this trivial solution:

Button {

    Component.onCompleted:{
        completed = true;
        updateTrack();
    }

    property bool completed: false
    property PlaylistTrack playlistTrack
    onPlaylistTrackChanged: {if(completed)updateTrack();}

    Connections {
        target: playlistTrack
        function onTrackChanged(){updateTrack();}
    }

    function updateTrack()
    {
        ...    
    }
}

Just in case someone comes along.
And do not use only a connection to trigger something (e.g. show something), always tie it to a property!
So long, thank you, guys, i wish you the best!

Asperamanca

I prefer less logic in when I call a function, and more logic where the function simply exits when some parameters are still missing, but that's a...philosophical difference.