orontee / argos

Light weight front-end for Mopidy music server
GNU General Public License v3.0
23 stars 4 forks source link

Play buttons #37

Closed canddoki closed 2 years ago

canddoki commented 2 years ago

@orontee At first many thanks for your work in the past days. The library and the album-view are running perfectly. I am not a programmer, but during usage over the last few weeks I got same ideas. Something is probably impossible ;-), but something mayby not. Handling the play- and add-button in Argos is, in my opinion, still a bit difficult for the children and me too ;-). It's also really difficult to implement and even make it usable for a touchscreen. Below are a few thoughts... For example Iris and iTunes solve this with a bar on the bottom, that shows what’s now playing, player-controls, etc.. But I think for this age group and me, it’s not the optimal solution. An idea could be the strictly split between simple hearing of an album and queuing resp. playlist management. In the albumview, on the bottom we could have buttons, like a classical cd-player. Click on play, the hole album is playing, forward, backwards and on eject, stop playing and go back to the library. On top of the list there are buttons for selecting / deselecting tracks, add these tracks or adding the hole album to the queue. If the selection-button was clicked, every track gets a check-box and can selected or deselected. Press add-tracks all selected tracks are added to the queue or press play and all selected tracks will be played simply. Every action after the begin of selection stops the selection mode and resets the button.

argos_albumview argos_albumview_select

Same behavior with tracks of playlists or hole lists …

argos_playlist

and for deleting selected track in the Playing tab.

argos_playing

Maybe in a later stadium - beside the trash is enough space for up and down arrows to sort selected items and for overwriting the list. Saving as new list is on a touchscreen probably only possible with an overlay keyboard.

Preferences and CLI-options I like the enhanced preference dialog. For easier operation maybe some CLI-options could move at this location. And an option on which tab Argos starts with would be good :).

orontee commented 2 years ago

@canddoki Thanks for sharing your thoughts.

Handling the play- and add-button in Argos is, in my opinion, still a bit difficult for the children and me too ;-). It's also really difficult to implement and even make it usable for a touchscreen. Below are a few thoughts...

I don't understand what you mean by "It's also really difficult to implement". Could you elaborate?

For example Iris and iTunes solve this with a bar on the bottom, that shows what’s now playing, player-controls, etc.. But I think for this age group and me, it’s not the optimal solution.

Yes, I made the same analysis. It consumes too much screen space too. That's the reason why I introduced a "Playing" tab in Argos: To avoid repeating the playing controls in albums and playlists views.

An idea could be the strictly split between simple hearing of an album and queuing resp. playlist management.

I don't understand how queuing could be separated from albums or playlist. One must select tracks to be enqueued. But I am not sure I understand correctly.

On top of the list there are buttons for selecting / deselecting tracks, add these tracks or adding the hole album to the queue. If the selection-button was clicked, every track gets a check-box and can selected or deselected. Press add-tracks all selected tracks are added to the queue or press play and all selected tracks will be played simply. Every action after the begin of selection stops the selection mode and resets the button.

Multiple selection of tracks in album and playlist views has landed on master branch few days ago. It's not implemented exactly as you suggest but please try it. That said you'll have to abandon the "single-click" option... Honestly the way multiple selection is currently handled is provided by the GTK toolkit, it's standard and I am not convinced one should try to invent a different way of achieving multiple selection.

Don't forget that Argos is also a desktop application; It tries to follow Gnome user experience.

Same behavior with tracks of playlists or hole lists … (...) and for deleting selected track in the Playing tab.

If I understand your suggestion correctly, it's equivalent to what Iris and iTunes do: Duplicate the playing controls in the three tabs.

Hum... Okay, I think I see. Give me time to think to this.

Maybe in a later stadium - beside the trash is enough space for up and down arrows to sort selected items and for overwriting the list. Saving as new list is on a touchscreen probably only possible with an overlay keyboard.

Branch 10-provide-a-way-to-create-delete-and-populate-playlists implements the following operations on playlists: creation, deletion, renaming, adding/removing tracks. The keyboard is only needed to rename the playlist. It's rather stable and I'd be happy to have your feedbacks.

Preferences and CLI-options

Please feel free to create a dedicated issue and suggest what option should be moved to the preference dialog!

canddoki commented 2 years ago

@orontee Thanks for your quick answer and sorry I didn't explain myself well on the first point. The use of the touchscreen is currently well implemented. The implementation of my ideas for operation with a touchscreen was not easy for me. So that was no criticism, but rather respect :).

I don't understand how queuing could be separated from albums or playlist. One must select tracks to be enqueued. But I am not sure I understand correctly.

Not easy to explain. The separation would probably have to take place within Argos. I naively imagine there are three queues: the album-, the list- and the playing-queue. The album-view is like a separate "room". If I press play-album or play-track(s) here, Mopidy stops all other things and only this mini-queue is passed to Mopidy. If I eject the album, Argos sends "Stop" to Mopidy, clears that queue right away and switch to the library. If I want to add the album or track(s) from there to Playing-tab, they are added to the Playing queue and nothing else happens for now. After I've finished adding, I switch to the Playing-tab, can still edit the list, start playback here or etc.. That's exactly how I imagine it with the lists. Within this tab, lists actually have the same status as albums in the album-view. I can play a list or tracks from it and when I switch the list it's like ejecting an album and thus clearing the list-queue.

Multiple selection of tracks in album and playlist views has landed on master branch ...

I like the single-click-option too much :). So let's postpone that until later. If I ever find time, may I could deal with Gtk-gestures and a --touchscreen option.

If I understand your suggestion correctly, it's equivalent to what Iris and iTunes do: Duplicate the playing controls in the three tabs.

I don't know exactly. If I leave the Album- or the List-tab to the Playing-tab, Mopidy should stop and so the playing-controls are not assigned. In the other direction, I'm not sure, Mopidy should also stop, isn't it?

Branch 10-provide ...

I will definitely do it.

canddoki commented 2 years ago

@orontee So, back from holydays :).

That said you'll have to abandon the "single-click" option...

For the past few days I've been trying Argos without the "single-click" option. I should have tried this earlier ;-). Now play and add buttons in the album view make sense, I can select single or multiple songs, play them or add them to the queue > simply perfect. What is difficult is selecting an album in the albumsview. Double-clicking on my touchscreen sometimes works, but mostly not. My question: Why do you need the double-click, for example in the albumsview? Even Argos is running on the desktop, a single-click on an album should be fine, right? Maybe it's possible to omit the double-click in places where it doesn't interfere with the desktop? What do you think? If it worked, the cli option single-click could be dropped... and issue #37 would be solved :).

orontee commented 2 years ago

What do you think?

Good point! I'll try to enable single click selection in the album view. I'll keep you informed.

One problem I see: When the raspberry pi screen goes in standby mode and one touch the screen, I guess the details page for the album under the finger will open. This may be disturbing since one doesn't see that album! But we already have this problem in other views with the "single-click" option, so I'm fine with this. We'll have to solve it in a different way.

orontee commented 2 years ago

@canddoki The 37-play-buttons branch enables single click selection in albums view and removes the --single-click option. I've not tested on my raspberry pi. As a desktop app, looks good.

canddoki commented 2 years ago

@orontee Thanks a lot for your fast reply and the changes.

One problem I see: When the raspberry pi screen goes in standby ...

Yes, I had that first-click-problem too. A simple lock screen that unlocks with a tap would be good. Unfortunately I couldn't find anything like that. I use xssstart (https://github.com/zpfvo/xssstart) in conjunction with clicklock (https://github.com/zpfvo/clicklock) and it works very well for me. I'll test the 37-play-buttons branch and get back to you.

canddoki commented 2 years ago

@orontee I need a hint: Before I create the deb-file I do 'git fetch origin' and than 'git checkout -b 37-play-buttons origin/37-play-buttons', but I couldn't get a deb-file with the right branch. Forgot I something or do I something wrong? Thank you

orontee commented 2 years ago

@canddoki I guess you build using the instruction in the README.md file and forgot to change main to HEAD or 37-play-buttons in the git archive command?

(Note that branch 8-provide-a-way-to-search-albums-by-artist as been rebased on top of 37-play-buttons so you can try both features at the same time...)

canddoki commented 2 years ago

Yeah, thank you :).

orontee commented 2 years ago

Yes, I had that first-click-problem too. A simple lock screen that unlocks with a tap would be good. Unfortunately I couldn't find anything like that. I use xssstart (https://github.com/zpfvo/xssstart) in conjunction with clicklock (https://github.com/zpfvo/clicklock) and it works very well for me. I'll test the 37-play-buttons branch and get back to you.

I tried the ubiquitous xscreensaver and... it does the job!

orontee commented 2 years ago

I am closing this since there's no activity.