Sorry, forgot to write a comment. This is not meant to be merged right now, I wanted to start a discussing which type of menu Elisa should use, e.g. the item-based (standard qqc2) or the native one (Qt.labs).
Both currently have issues which need to be fixed first.
I have at least an idea what could be done to fix the item-based solution, and I have no clue what's going wrong with the native solution.

Working good so far. Memory usage seems to have dropped a little with my smaller music collection. Tracks with an empty artist tag are also correctly displayed in the all tracks view.

In D16302#361032, @astippich wrote:

Since this revision is quite large, it's probably difficult to review it properly. I'm going to let it run a little and report back in case I find any issues.

• fix errors when inserting multiple albums with same title
• really cache only artists and not the other people
• fix import of tracks with paths containing particular character like { }

In D16944#362538, @mgallien wrote:

After the tests I had done, I am convinced that we should first fix the stack used by Elisa before pushing this kind of changes.

The menu is no longer a sub window manage by the windowing system. Is this really a good idea ?

In D16302#361032, @astippich wrote:

Since this revision is quite large, it's probably difficult to review it properly. I'm going to let it run a little and report back in case I find any issues.

• rebase
• cleanup

Since this revision is quite large, it's probably difficult to review it properly. I'm going to let it run a little and report back in case I find any issues.

• allow tracks without artist

• reduce overhead from AllTracksModel
• reduce overhead of AllAlbumsModel and make it synchronous
• do not list files too early from Baloo
• keep all files discovered from a source and fix a minor related issue
• add a test for DatabaseInterface::askRestoredTracks
• add albums and artists cache and improve cache usage
• improve management of files not modified since last scan of music files

ping

thanks

Sorry for the delay

• reduce overhead from AllTracksModel
• reduce overhead of AllAlbumsModel and make it synchronous
• do not list files too early from Baloo
• keep all files discovered from a source and fix a minor related issue
• add a test for DatabaseInterface::askRestoredTracks
• add albums and artists cache and improve cache usage
• improve management of files not modified since last scan of music files

D16659 and its dependent revision will allow to remove custom styling in the future

• rename to FlatButtonWithToolTip

I lack time until next week for a proper review.

In D13872#352380, @astippich wrote:

In D13872#350907, @mgallien wrote:

In D13872#345491, @astippich wrote:

see D16284

I have been working on this subject to help come this diff come to a conclusion. Thanks for your work on this as it is important.

I believe that we have been overusing ToolButton at places just to get a flat look instead of doing the proper job (i.e. customizing the look of a Button component).

I also better understand (thanks to D16284) why we get icon+text. I believe that this will not change as it is done on purpose to maximize compatibility with QWidget equivalent of ToolButton. We are the guilty ones here given we had used ToolButton components in places where we expected a custom behavior (i.e. no text).

I have a private (at the moment) branch with no QQCv1 components. There are several regressions. I had kept overusing ToolButton like in master branch.

I would like to try to come up with a long term and maintainable solution for each of our button cases:

• flat button with text and icon ;
• flat button with tooltip and icon ;
• flat round button with icon ;
  
  The result should be fully usable with keyboard only, mouse+keyboard and touch screens. That means that ToolButton as is is not the solution because the focus behavior is not going to work for keyboard only usage. Our solution should work with org.kde.desktop and Fusion style (at least).

I've gone ahead and factored out the current button code that was copied all over in MediaPlayerControl. As it is now, it's mostly a refactoring only with the exception that actions are now used.
Imho we don't need a round button anymore.
If you agree on the implementation, I will roll this out to all qqc1 toolbuttons in the views and playlist.

In D13872#350907, @mgallien wrote:

In D13872#345491, @astippich wrote:

see D16284

I have been working on this subject to help come this diff come to a conclusion. Thanks for your work on this as it is important.

I believe that we have been overusing ToolButton at places just to get a flat look instead of doing the proper job (i.e. customizing the look of a Button component).

I also better understand (thanks to D16284) why we get icon+text. I believe that this will not change as it is done on purpose to maximize compatibility with QWidget equivalent of ToolButton. We are the guilty ones here given we had used ToolButton components in places where we expected a custom behavior (i.e. no text).

I have a private (at the moment) branch with no QQCv1 components. There are several regressions. I had kept overusing ToolButton like in master branch.

I would like to try to come up with a long term and maintainable solution for each of our button cases:

• flat button with text and icon ;
• flat button with tooltip and icon ;
• flat round button with icon ;
  
  The result should be fully usable with keyboard only, mouse+keyboard and touch screens. That means that ToolButton as is is not the solution because the focus behavior is not going to work for keyboard only usage. Our solution should work with org.kde.desktop and Fusion style (at least).

• do not use toolbutton

I think you need to install the Qt5CorePrivate development files

In D13872#350907, @mgallien wrote:

In D13872#345491, @astippich wrote:

see D16284

I have been working on this subject to help come this diff come to a conclusion. Thanks for your work on this as it is important.

I believe that we have been overusing ToolButton at places just to get a flat look instead of doing the proper job (i.e. customizing the look of a Button component).

I also better understand (thanks to D16284) why we get icon+text. I believe that this will not change as it is done on purpose to maximize compatibility with QWidget equivalent of ToolButton. We are the guilty ones here given we had used ToolButton components in places where we expected a custom behavior (i.e. no text).

• additional fix for the test

In D13872#345491, @astippich wrote:

see D16284

I tried to take another look at this, but after rebasing on master I started getting an error when building:

Since this test is currently failing, shall I land it and it will be fixed afterwards?

Nice, thanks

Thanks. I have two more comments inline.

see D16284

• let kirigami be required only on Android

• only add test for empty artist

In D16193#344766, @mgallien wrote:

In D16193#342774, @astippich wrote:

• cleanup

I am working on a refactor of the database that includes removing the TracksArtists table. That should make it very easy to implement this feature. Could you only add the automatic tests with expected failure and I include this in my patch ?

• restore previous behavior for mediayplaylist

• reorder include

In D16193#342774, @astippich wrote:

• cleanup

The code was in KFileMetaData, and I just bumped to required version in Elisa to v5.48 (D16175).
So now someone can actually start working on implementing

Thanks for your work

How is this feature advancing? Because I see there was a diff and a commit concerning it, but the code isn't on master I don't think.

I'll try to look into this again next weekend. I think Elisa was missing some way to go properly from Now Playing to a specific album view, so it went straight to all albums.

In D16194#342832, @astippich wrote:

Unfortunetaly, due to your request of making the creation of trackslistener on demand (D15078), they are quite some #ifdefs in musiclistenersmanager. But I don't know how to do it better than this.

Unfortunetaly, due to your request of making the creation of trackslistener on demand (D15078), they are quite some #ifdefs in musiclistenersmanager. But I don't know how to do it better than this.

• cleanup

This is currently not fully working yet. I could verify that the track gets added correctly to the database, and the artist query is correctly skipped. But the track is not fetched from the database with the selectTrackFromIdQuery, and hence the test fails. I'm no expert in SQL, and haven't found a solution for that yet, so any help is appreciated.

I'm currently quite busy with other things and would like to finish more of that before adding stuff to my todo list again...

• make const ref and use auto
• fix test

In D14018#314793, @januz wrote:

This is mostly done too but there's still one small bug: when I go to the now playing view and then click on the album name it doesn't open the album, but only switches to the album view.
Still trying to figure this out

I still have high doubt with your current approach (ElisaToolButton). See my inline comment.
I fear that with your patch patch we increase the maintenance cost and add more things to learn for newcommers.

master branch of Elisa is now using vlc to play music. This allows to have a very good out of the box experience on Windows.
I need to improve craft packaging to decrease package size.