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.

ping

ping

• rebase
• explicitly forbid tracks with empty title and artists for now
• alter one of the test file to be incomplete

In D14120#339355, @januz wrote:

Hi guys, sorry I've been dropping the ball on this one. I had reverted this some weeks ago but couldn't find another way to center it. And then I didn't have time to get back on it.
+1 for landing it now

Thanks for your work.

In D13685#338357, @astippich wrote:

@mgallien could you comment if this is acceptable or not?
I think right now is a good time to merge it into master. I expect there to be at least some issue with the GUI where we previously always expected a value, and it would give some time to sort all issues out before the next release.

In T9811#163369, @bcooksley wrote:

This has now been deployed.

This has now been deployed.

Hi guys, sorry I've been dropping the ball on this one. I had reverted this some weeks ago but couldn't find another way to center it. And then I didn't have time to get back on it.
+1 for landing it now

• remove explicit this->