I am working on a detailed feedback but I have already a few remarks.
I am no longer able to use Elisa with my touchscreen. Without your modifications, it is possible to touch an album to get the buttons and then act like if I had a mouse. With your patch, I am only able to enter into an album but not enqueue it. One possibility is maybe to use dedicated components for detecting touch interactions.

I am not convinced that we can change the size of cover images without allowing the user to configure it to its liking (I am thinking of what is implemented in Dolphin as in 18.08 version). What do you think ?

Overall, I need to get used to the changes but I agree with most of them.

In D20581#450845, @mgallien wrote:

I am working on a detailed feedback but I have already a few remarks.
I am no longer able to use Elisa with my touchscreen. Without your modifications, it is possible to touch an album to get the buttons and then act like if I had a mouse. With your patch, I am only able to enter into an album but not enqueue it.

This is a generic problem with using hover-based user interfaces that's sort of unsolvable. However, note that no features have been lost for touch users and it is still possible to perform these actions via the buttons above the grid view: first you tap an album to enter it, then you tap "Enqueue" or "Replace and Play". This is only two steps, which is the same number of steps previously required (tap album to display hover buttons, tap inline button corresponding to desired action).

I am not convinced that we can change the size of cover images without allowing the user to configure it to its liking (I am thinking of what is implemented in Dolphin as in 18.08 version). What do you think ?

I agree, making it user-configurable might be nice. However a good default size would tamp down on the desire for that. If you feel that these are too big now, here's 170:

This is almost exactly the size of Lollypop's grid delegates, which feel just about right to me.

In D20581#450868, @ngraham wrote:

In D20581#450845, @mgallien wrote:

I am working on a detailed feedback but I have already a few remarks.
I am no longer able to use Elisa with my touchscreen. Without your modifications, it is possible to touch an album to get the buttons and then act like if I had a mouse. With your patch, I am only able to enter into an album but not enqueue it.

This is a generic problem with using hover-based user interfaces that's sort of unsolvable. However, note that no features have been lost for touch users and it is still possible to perform these actions via the buttons above the grid view: first you tap an album to enter it, then you tap "Enqueue" or "Replace and Play". This is only two steps, which is the same number of steps previously required (tap album to display hover buttons, tap inline button corresponding to desired action).

The current delegate support the following actions:

• single click select it and make it the current item of the view and show the on hover decoration (i.e. the buttons) ;
• double click open the child view.

Your patch changes it to be single click to open but adds no way to select it (and make it the current item of the view).

Making it the current item of the view allow to use keyboard navigation of an item that is selected.

There is also another consideration to have that we will want to eventually have multiple selection of entries.

I will have a look at MultiPointTouchArea to see if that could be a solution for touch interaction.

For user interfaces where you want single-click-to-open, but allow multi-item selection, I think a dedicated selection mode is generally the way to go. On mobile, entering this mode is accomplished by pressing -and-holding on an item (Android) or tapping the Select button on a toolbar somewhere (iOS). On the desktop, those would be supplemented by the typical ctrl+click selection method for expert users who use keyboards shortcuts.

I've been wanting to get this interface implemented in KDE software for a while now, see T9895: Improving single-click / creation of contextual action toolbars.

In D20581#451928, @ngraham wrote:

For user interfaces where you want single-click-to-open, but allow multi-item selection, I think a dedicated selection mode is generally the way to go. On mobile, entering this mode is accomplished by pressing -and-holding on an item (Android) or tapping the Select button on a toolbar somewhere (iOS). On the desktop, those would be supplemented by the typical ctrl+click selection method for expert users who use keyboards shortcuts.

I've been wanting to get this interface implemented in KDE software for a while now, see T9895: Improving single-click / creation of contextual action toolbars.

It would probably a good idea to split this review between the graphical changes and the behavior changes. For the behavior changes, I believe that it is a good idea to add a selection mode. In the current state of the diff, it looks to me like a regression to lose the ability to select an item to allow interaction with it (button access when using laptop touchscreen, navigating with keyboard, ...).
What do you think ?

I can split the diff to remove the click changes, sure.

Note that both technically and in principle, selection can and should still be possible even with a single-click UI that lacks a dedicated selection mode: when the view has focus, using the arrow keys should simply cause an item to become visibly selected.

Friendly ping :)

Oops, I didn't even run the tests, sorry. I will in the future before posting patches. Will fix and then commit.