Some User Interface Feature Requests

[erasmus]

WACUP UI related Feature Requests

[-1-]
File Explorer view built into Local Library that can traverse within subdirectories of user defined directories similar to how USB removable storage is accessed.  This can be of use to users who keep certain audio files outside of their main library (like say podcasts, spoken word audio, unfinished/temporary audio projects, etc....)

[-2-]
Currently it can be finicky to slide from one nested list to a child nested list on High DPI displays and/or with high DPI mouse sensitivity.

*Example* - Right-Click a "Now Playing" playlist item then selecting "Send To" nested list then having to slide across a narrow pixel area to get to the "Send To" list and then rinse/repeat to slide to "Library Playlist" nested list.  During either operation if mouse cursor strays out of narrow pixel area ("Send To" list or secondly "Library Playlist") the list disappears and user must restart action.

*Attachment pics 1 + 2 show this part of the UI I speak of.

Solutions to above issue -

-- Increase the height of entries that are nested lists.  Maybe allow the user to choose double or triple height (or fractionals like 2.5 height but maybe that is overkill).

-- Or as an alternative - allow users add "connected" separators (line elements) to right-click pop-up items (maybe through a Right-Click preference page/tab, or maybe just default for nested list items) that either sit adjacent above or below (or both) the highlight-able item and is considered part of the item for highlighting/mouse-cursor-motion purposes.  Thus giving the user more leeway moving around these items in high DPI situations.

-- Or maybe set a modifier key (Alt ot Ctrl or Shift or a combo) to "hold" or "lock" the nested item to be highlighted and focused even if the mouse moves out of it's pixel area.  This would also be useful for the following feature request.

 
[-3-]

Increase usability of [Right-Click Menu -> Send To -> Library Playlist], hereafter called [RtClk-Library Playlist]. 

I use this item a lot while listening to new or recently re-tagged music and I like to populate my playlists with it.  But currently it could use some attention.  As described above it can be frustrating to even arrive cleanly at this part of the interface but I separated that issue since it pertains to all the nested lists imo.  However there are a few things that need attention in this particular item.

-- Closes abruptly after sending the highlighted track to a single playlist.  This is maybe an ok default for some users but I often want to send the same track to multiple playlists. 

*Example* Listening to a new album.  Track #1 - I want to send this to playlist "Monday", "Wednesday" + "Saturday".  Track #2 - Send to playlist "Tuesday" + "4thOfJuly". /*Example*

To perform these actions I have to right-click and get to the [RtClk-Library Playlist] Five(!) times and I'm only two tracks into my new album.  With a Twenty track album and a number of playlists that might be invoked this quickly becomes tedious. 

So if in someway we could keep this particular menu locked open for multiple "send to playlist" actions that would be a great help.  It would require being called up only once per track which would make for a much easier user experience.  One solution might be the suggestion above to have a modifier key or combo that "holds" or "locks" the [RtClk-Library Playlist] open for multiple actions.

-- To go in conjunction with the previous issue, show if the current highlighted track is currently in the any playlists within the [RtClk-Library Playlist] using a checkbox.  I show below a screenshot from Quod Libet (native Linux Winamp competitor) how theirs' looks as an example in *Attachment* pic #3.

A "checked" checkbox denotes the track is present in the playlist, an empty box denotes the track's absence. This makes it very easy to add or remove tracks, provided the [RtClk-Library Playlist] element stays open while checking or unchecking boxes. [As an aside Quod Libet also currently closes after a single action  ]

---Lower Priority requests -------

Have right-click pop-up be skinned by Skin Theme.


Thanks for reading!  I hope I was able to convey my thoughts understandably. 
And that the suggestions are of utility to average users. 

Go WACUP! 

[erasmus]

I've done some more reading of the preview build threads and see how the core is getting attention first before wrapping back around to things like skinning and I agree with those priorities. (Also mention in reply to my other thread, thanks).

 I may still add things to this thread as I encounter them but it's just to get the ideas down without forgetting about them and not meant as a nag or complaint or anything. 

Glad to see the progress we've been seeing lately and the more frequent builds!

Go WACUP! 

[dro]

Adding to the thread is fine as I'll use what's posted in them to keep a track of things & will split out as needed if it makes sense.

So having a quick read through the initial points, the first is already on the list & is to follow on once the local library plug-in has been replaced (it has a few areas that leave it lacking compared to the existing ml_local.dll from 5.666 & so that needs to be done before adding additional view modes).

With the right-click menu, I've a feeling most of the issues you've having are due to running it under WINE as it is also meant to be skinned by default which does work on Windows. Trying to circumvent click areas & the likes I really don't want to try to do (which would involve making my own menu control & that's more effort than would be returned). If the menu was being skinned like I see it under Windows then it'd be easier to just bump the font size used for the skinned aspects & that might alleviate some of the issues. Ultimately its down to the OS to nicely handle such things imho than for me to attempt to hack around things & is why Quod Libet is going to respond in a similar manner as menus are meant as one off actions.

However, with the main thing that you're wanting to do (send the same file to multiple playlists), the better option would be to adapt the non-menu solution (preferences -> media library -> send to options -> uncheck 'Show all playlists on the send to menu' & you then get one 'library playlists' option & a dialog with the playlist to send to. It would be much easier for me to modify that (as well as you then just have one item to click) to have checkboxes next to the playlists (I'd have to make it a list instead of a drop down to make it easier to work with them which might be better to do anyway). That seems like it would be the easiest way to achieve most of what's wanted & not have to attempt hacks.

Having the send-to selection highlighted in the playlist(s) is a potential performance nightmare as it's ok with a single selection &a few small playlists but it'd get mess fast with multiple selections as send-to allows & with lots of large playlists (note: I've never tried Quod Libet so I don't know how it fares). Maybe the dialog option above can remove some of that pain but I'm not sure what benefit it would offer other than to see if it'll cause duplicates - if that's the case then it might be better for the playlist handling to do that when trying to send something (controlled via an option) as you then just take the hit when the playlist is changed instead of doing it in all cases as would typically be happening if the action isn't completed.

I think that's covered the main points you've raised & now I'll get some sleep, heh.

-dro

[erasmus]

However, with the main thing that you're wanting to do (send the same file to multiple playlists), the better option would be to adapt the non-menu solution (preferences -> media library -> send to options -> uncheck 'Show all playlists on the send to menu' & you then get one 'library playlists' option & a dialog with the playlist to send to. It would be much easier for me to modify that (as well as you then just have one item to click) to have checkboxes next to the playlists (I'd have to make it a list instead of a drop down to make it easier to work with them which might be better to do anyway). That seems like it would be the easiest way to achieve most of what's wanted & not have to attempt hacks.

-dro

Yes my main point was greater ease with sending a track to multiple playlists.   The breakout of the Library Playlists seems a good way to get there.

 

In the meantime uping the system font size in the WINE prefix helped quite a bit.  Thanks!