As this is my first attempt to do something a little bit more complex on the c++ side, please test and review carefully. Next step is to display it in the details view. For this, I would like to turn the class MusicAudioTrack into a QObject so that we can access the data in Qml. The audiotrack would then get passed to the delegates and we would not have to query each data separately in the model. Is this okay?

In D10008#194054, @astippich wrote:

As this is my first attempt to do something a little bit more complex on the c++ side, please test and review carefully. Next step is to display it in the details view. For this, I would like to turn the class MusicAudioTrack into a QObject so that we can access the data in Qml. The audiotrack would then get passed to the delegates and we would not have to query each data separately in the model. Is this okay?

You have my complete support for this work.
I am not really able to answer right now. I have some points to raise but nothing definitive yet.

If you make MusicAudioTrack being a QObject you will lose the ability to use operator = and may need to modify quite some code.

For some time, I have been planning to do a benchmark of the c++ code without the qml part. That means, I would like to analyze the code of the elisa files indexer and the database. I can test the two scenario (current code and with MusicAudioTrack being a QObject).

Did you consider having a role with all metadata that would be in a list that would act like a model for the ui part ? This may be a bit easier for not hardcoding too much thinks in the UI (the metadata being defined or not, ...).

The reason why I wanted to make the audiotrack a q object is that there would be no duplication of data, e.g. copying all the values around. But if this causes a lot of work, I might choose a different path then. Creating a little helper with a model that can be accessed from the listview sounds like good plan.

Are you okay with merging this diff without this (maybe after you tag the next alpha?) or do you prefer to wait until I have a complete solution ready? The database is already populated correctly and the data is accessible, at least during my testing.

In D10008#195181, @astippich wrote:

The reason why I wanted to make the audiotrack a q object is that there would be no duplication of data, e.g. copying all the values around. But if this causes a lot of work, I might choose a different path then. Creating a little helper with a model that can be accessed from the listview sounds like good plan.

In fact my point is really that I do not know the real impact on adding inheritance to QObject.

Are you okay with merging this diff without this (maybe after you tag the next alpha?) or do you prefer to wait until I have a complete solution ready? The database is already populated correctly and the data is accessible, at least during my testing.

I will finish reviewing the current diff as fast as I can. I am happy with the current state. Thanks this is a nice addition.

Alexander, you can integrate. Nice work.