use KDE_INSTALL_FULL_LIBDIR instead of the non working current solution

I will update it and land it.

Do you want me to push a fix or are you able to do it directly ?

I have found a working solution. See my inline comment. Do you want me to push a fix or are you able to do it directly ?

It might be caused by my default cmake parameters on my distro (Fedora):

Forgot what I said. It looks like CMAKE_INSTALL_PREFIX may be unnecessary. I thought I needed it to get correct installation paths.
Sorry about my confusion.

Thanks for taking care of that.
I am a bit lost at what is the cause of your problem.

Ability to read the ReplayGain tags will be released in kfilemetadata as part of KF 5.51

What is your rationale for this change ? I do not agree that we should change things when not needed by some other code changes. Even if there exists some automatic tests, the coverage is not good enough to guarantee that we will not have regressions.

The playlist is a very different case where some data come asynchronously. I am not convinced there is a way to have common code between models where one always gets a MusicAudioTrack and models where one does not always have a MusicAudioTrack. Please check.

In D14126#327753, @astippich wrote:

In order to avoid polluting the mediaplaylist with a QMimeDataBase, I decided to move the handling to the proxy model. Let me know what you think.

The music collections is in an external drive and was probably not indexed by baloo. I can do some test with the external drive mounted somewhere in my home directory and indexed by baloo.

In T7597#161567, @ognarb wrote:

I don't use Elisa anymore (Elisa couldn't handle my 1Tb music collection). So I stopped working on this task.

I don't use Elisa anymore (Elisa couldn't handle my 1Tb music collection). So I stopped working on this task.

In D15607#329852, @astippich wrote:

I think there is still one issue: when the view is not collapsed and you click on e.g. artist view, the search field also doesn't get focus immediately. but it's an improvement anyway

• use tooltip directly

I think there is still one issue: when the view is not collapsed and you click on e.g. artist view, the search field also doesn't get focus immediately. but it's an improvement anyway

I removed the override.

• remove function override

In D13872#328309, @mgallien wrote:

I do not understand your intent with this patch. Especially the way you provide a special ToolButton with a lot of things in it.
Please explain better why each element in ElisaToolButton is here ?

As an example, I did try this:

I have spent some more time looking at your patch and fail to see the rationale behind the way tooltips are added. Did you try the ToolTip attached property ? That would be the "good" way to do it.

I do not understand your intent with this patch. Especially the way you provide a special ToolButton with a lot of things in it.
Please explain better why each element in ElisaToolButton is here ?

I cannot really comment on the technical side of things as I am unfamiliar with it, so only tested as usual. Also a small reduction in memory usage here, and works fine.
You have again some changes for the theme file included which should not be here after rebase.

In order to avoid polluting the mediaplaylist with a QMimeDataBase, I decided to move the handling to the proxy model. Let me know what you think.

• rename enums, handle loading of playlist differently

I forgot for a second that you don't need video support. Well I'm not entirely sure if QtAV supports many audio formats, but it depends on ffmpeg which I believe support many. I have very little knowledge here and just wanted to add some info about the existence of QtAV :)

In T7184#160231, @safaalfulaij wrote:

Digikam switched to QtAV once and they said it's better for cross-platform. It also has a QML interface and a similar API to Qt Multimedia. I think you should check that first before VLC.

Digikam switched to QtAV once and they said it's better for cross-platform. It also has a QML interface and a similar API to Qt Multimedia. I think you should check that first before VLC.

In D15484#325459, @mgallien wrote:

The different titles are no longer aligned. Please fix that. It is important that the album title is aligned with tracks title.

• restore previous behavior of album cover margins again

okay, wiped everything and retried, works now and this patch fixes the bug

The different titles are no longer aligned. Please fix that. It is important that the album title is aligned with tracks title.

yes, elisa does not show any tracks first, but if baloo is enabled they start to appear

rebase on top of 0.3 branch

In D15298#325421, @astippich wrote:

I already did that, and in both cases tracks showed up. will try once more

I already did that, and in both cases tracks showed up. will try once more

In D15298#325370, @astippich wrote:

I can't reproduce. What's the exact test plan?

Before

ping. would be a shame to let this one go to waste so close to merging

I can't reproduce. What's the exact test plan?

In D15200#324231, @astippich wrote:

In D15200#321580, @mgallien wrote:

In D15200#321478, @astippich wrote:

Yes, this is supposed to fix the issue with the album header. The removal of the brightness contrast is actually unrelated to this, but it seemed unnecessary while looking at it.

Imho if adding a simple margin setting to an item in an unrelated qml row leads to these bugs, this code is quite fragile. I also don't know what all the math is about for a simple layout margin of an image for the main icon.

I have created D15322 with a proper fix for the album header bad handling of different font sizes.
This is a general problem in many layout in Elisa, they do not play nicely with different font sizes.
I fail to see how this review deal with this.

Now I am a bit confused. Is this the root cause? Can 0d5fbd5474eb now be applied again? Because I think it looks more polished and consistent if the indicator has some margin like everything else.
I factored out the changes with the BrightnessContrast into D15434 since they are unrelated

Thanks

In D15200#321580, @mgallien wrote:

In D15200#321478, @astippich wrote:

Yes, this is supposed to fix the issue with the album header. The removal of the brightness contrast is actually unrelated to this, but it seemed unnecessary while looking at it.

Imho if adding a simple margin setting to an item in an unrelated qml row leads to these bugs, this code is quite fragile. I also don't know what all the math is about for a simple layout margin of an image for the main icon.

I have created D15322 with a proper fix for the album header bad handling of different font sizes.
This is a general problem in many layout in Elisa, they do not play nicely with different font sizes.
I fail to see how this review deal with this.

Before

In D15200#321478, @astippich wrote:

Yes, this is supposed to fix the issue with the album header. The removal of the brightness contrast is actually unrelated to this, but it seemed unnecessary while looking at it.

Imho if adding a simple margin setting to an item in an unrelated qml row leads to these bugs, this code is quite fragile. I also don't know what all the math is about for a simple layout margin of an image for the main icon.

ping, rolling this out would be a great step forward for a pure qqc2 application

ping. we have multiple bug reports about this

Yes, this is supposed to fix the issue with the album header. The removal of the brightness contrast is actually unrelated to this, but it seemed unnecessary while looking at it.

I am a bit lost. Is this diff supposed to fix the misalignment regression in playlist entries ?
I have identified commit 0d5fbd5474eb96989c5066b2f406c6b00ef7ee23 to be the one responsible for the regression I am seeing.
with D15200:

I am using the packages produced by binary-factory.kde.org using Craft at work and usually fix issues with the Windows version when I noticed them.

Sorry for the late reply.

• directly query track list from music album

I also have mixed feelings about this since it somewhat duplicates the top bar. Just a very slim progress indicator beneath the title without the ability to seek would suffice. One could also think of making the complete background a progress bar, maybe with a light blue or gray color.

It is working fine. Thanks for this work.
I have a few remarks. I would prefer a smaller progress bar without the handle and read-only. This would make it a nice way to visualize the currently playing track and at the same time the track progress.
What do you think ?
@januz, @astippich, @ngraham what do you think ?
I will have a look at the alignments also without your patch as it seems we have broken something here.