sorry, even an arrow pointing in the opposite direction or a circle or so would be much less confusing imho. Perhaps the Breeze icon theme has such icons...

We're using the `go-next-view-page` icon, which is semantically correct; the action does indeed take you to the next view page. In Breeze, the icon is a rightward-facing arrow similar to the one in your icon theme.

So the objection here is that the icon does not communicate "clicking on this will take you to the next page". An eyeball icon would not work; we use that to communicate visiblity/hidden status. Do you have any other suggestions?

Maybe instead we could make the icon show what it is you'll be taken to? So if clicking on it will take you to an album, it would show the album icon; if clicking on it would take you to an artist, it would show the artist icon, and so forth. One problem I can envision for this is that we would need icons for "artist" and "genre" that are perfect, or else the meaning will be totally lost. This seems like it might be impossible. The current ones are not that great IMO.

Any other ideas?

(In reply to Nate Graham from comment #2)
> We're using the `go-next-view-page` icon, which is semantically correct; the
> action does indeed take you to the next view page. In Breeze, the icon is a
> rightward-facing arrow similar to the one in your icon theme.
> 
> So the objection here is that the icon does not communicate "clicking on
> this will take you to the next page". An eyeball icon would not work; we use
> that to communicate visiblity/hidden status. Do you have any other
> suggestions?
> 
> Maybe instead we could make the icon show what it is you'll be taken to? So
> if clicking on it will take you to an album, it would show the album icon;
> if clicking on it would take you to an artist, it would show the artist
> icon, and so forth. One problem I can envision for this is that we would
> need icons for "artist" and "genre" that are perfect, or else the meaning
> will be totally lost. This seems like it might be impossible. The current
> ones are not that great IMO.
> 
> Any other ideas?
 
Do we need the button there in the first place? Currently, you can double click to enter an album, artist or genre grid item. Even then, I don't see any reason why double click is needed. You can't select multiple grid items. Rather than having a dedicated floating button, why not just make single clicks  open the album/artist/genre grid item?

I proposed that about a year ago. Lollypop implements it this way, with single-click being used to enter an item.

IIRC the objection back then was that enter-on-single-click would make it difficult or impossible to select an item, which makes the inline buttons appear. This is not a huge deal for pointing device users since they also appear on hover, but for touch users, selecting an item is the only way to make the inline buttons appear.

However maybe we could accept that touch users would need to enter an item and use the play now/enqueue button from the toolbar rather than using the hover buttons.

Thoughts, Matthieu?

(In reply to Nate Graham from comment #4)
> I proposed that about a year ago. Lollypop implements it this way, with
> single-click being used to enter an item.
> 
> IIRC the objection back then was that enter-on-single-click would make it
> difficult or impossible to select an item, which makes the inline buttons
> appear. This is not a huge deal for pointing device users since they also
> appear on hover, but for touch users, selecting an item is the only way to
> make the inline buttons appear.
> 
> However maybe we could accept that touch users would need to enter an item
> and use the play now/enqueue button from the toolbar rather than using the
> hover buttons.
> 
> Thoughts, Matthieu?

For touch users, I don't think not having access to these floating buttons would be a problem if there was a very convenient way to go up and down list/grid levels. Right now, the only way to go back up to the previous level after entering an album is to click the little back arrow. I don't think that's very convenient, even for mouse/touchpad users. A breadcrumb and the ability to swipe right to go back would probably help improve the experience of navigation for both touch screen and mouse/touchpad users.

There are probably ways to also improve the experience of adding albums to a playlist for touch users that don't interfere with mouse/touchpad usage, but I can't think of much right now.
Maybe drag and drop? That could interfere with view swiping.
Maybe long press to enter selection mode so that pressing the queue button in the toolbar queues all of the selected items? Long press isn't very discoverable though.

Drag-and-drop from main view to playlist is planned BTW. That's something we want for pointing device input too. See Bug 415207.

I agree that a swipe-right-to-go-back gesture would work well for touch, but yeah, it would have to be carefully implemented and tweaked to not get in the way of the future drag-and-drop-to-playlist feature.

Long-press-on-view-items-to-enter-selection-mode may not be very discoverable, but it's at least fairly common on Android now.

(In reply to Nate Graham from comment #4)
> I proposed that about a year ago. Lollypop implements it this way, with
> single-click being used to enter an item.
> 
> IIRC the objection back then was that enter-on-single-click would make it
> difficult or impossible to select an item, which makes the inline buttons
> appear. This is not a huge deal for pointing device users since they also
> appear on hover, but for touch users, selecting an item is the only way to
> make the inline buttons appear.
> 
> However maybe we could accept that touch users would need to enter an item
> and use the play now/enqueue button from the toolbar rather than using the
> hover buttons.
> 
> Thoughts, Matthieu?

The touchscreen of my laptop is broken. I can no longer test or work on that. It is sad but I plan to keep this laptop as long as I can. I will see if I can get some alternative device to work on that.

Anyway, I believe that the InputHandler may allow to fine tune the interaction depending on the device used to interact.

In the meantime, we would need to have somebody actively involved to test and work on that. If this is not possible, we should avoid blocking progress and work on mouse interaction primarily.

About your specific question, I believe that this is an acceptable deal because the inner view should be fast to appear and provides the needed controls.

I have a last question, should we not try to follow the single/double click KDE wide setting ?

Thanks. I've submitted a patch: https://invent.kde.org/kde/elisa/merge_requests/78

I have a functional touchscreen and would be happy to work on touch support. Even touch scrolling seems broken now on the grid view. That's probably the first priority.

BTW, on the subject of respecting the double-click/single-click setting, here's my rule of thumb:

If the item can be meaningfully interacted with while selected, it should respect the setting. If not, it should be single-click only.

The grid delegates are a borderline case. While selected, those inline buttons appear, allowing interaction. However these buttons also appear on hover and are present on the main toolbar once the item is opened, so strictly speaking, selection to access the functionality isn't required. Therefore to me it makes sense to be single-click only.

(BTW I say this as a person who uses double-click)

Just fixed in https://cgit.kde.org/elisa.git/commit/?id=431072f2687e480dbfce2f079abb0e8f1e4d77dd; see https://invent.kde.org/kde/elisa/merge_requests/78