Thank you very much for reviving this great software ! I am now using it daily from flatpak, waiting for it to be in the official backport repos some day (I am on Debian stable ;-) ) This report is about the usability of the Context View applets in general. May be the title should be "The Context View should have predictable applet positions" ? since the user never know where to focus her/his attention after a mouse click. Sometimes, the applet is half displayed and one needs to scroll up or down (an extra action). SUMMARY Navigating between the applets in the context view is difficult, with multiple UI "knobs" to act on: a. the expand(arrow down)/shrink(arrow up-down) buttons for each applet, b. inner vertical (or horizontal) scrollbar for some applets (ex. Albums and Wikipedia), c. outer vertical scrollbar for the context view, d. and finally, the row of buttons at the bottom, for direct access to each applet, but they do not expand automatically the applet. There are many side effects between b. and c. when scrolling with the mouse wheel button: - for example, when scrolling with the mouse wheel button in an applet (ex. the albums), one ends up moving the whole context view stack (c. the outer scroll bar) unexpectedly if the inner scrollbar (b.) reaches its upper limits. - and inversely, one can start scrolling (c.), then the action switches to (b.) unexpectedly because the mouse action is intercepted by the applet that moves under the mouse pointer. In some conditions in the Albums applet, expanding to view a (long) album's track list shift the Context View stack up or down. As a result, the applets positions on the screen seem unpredictable. EXPECTED RESULT 1. The applets buttons at the bottom act as navigation tabs. Then, it may be easier and user-friendly to grant each applet its own full sized context view (~like in a web browser). 2. This would gives a predictable behaviour, no hazardous scrolling, and may give rooms to expand and customize the applets views. 3. The UI components (a.) and (c.) would be unnecessary, such as the option to customize the applet size (I know that it is hidden somewhere, in a place I could not find :-) Notes: -- The "current track" and five "similar artists" fit well in one context view tab. -- A tab with only "similar artists" can list more than five (if the user want to customize it as needed) -- A tab for "Albums" can show (and edit?) the tracks rating 🟊🟊🟊✩✩, instead of being a duplicate of filtering the library with the current artist name. As of now, if the track is not currently playing, the only possibility to view and edit the rating tag is to open the "Edit Tags" window (right-click on the selected track(s), one track at a time if the ratings are different) -- If unmodified, the "Albums" applet is also similar to a simple track menu action "Show artist" like the menu "Show media source" SOFTWARE/OS VERSIONS Amarok: flatpak version, app/org.kde.amarok/x86_64/stable 3.2.2 Linux/KDE Plasma: Debian Bookworm KDE Frameworks Version: 5.116.0 ADDITIONAL INFORMATION
Thank you for the report. There are multiple fine points there, I'll try to address the easiest one first: the option to customize the applet size (I know that it is hidden somewhere, in a place I could not find --> Indeed: context applets can be resized by enabling context view edit mode, and dragging from the highlighted lower edges of the applets. I added the highlight colour a year ago, but haven't come up with more ideas how to make it more discoverable, yet. Regarding the different navigation paradigms: I guess I had completely forgotten/ignored that a. expanding/collapsing applets exists, as I've never used it myself. Maybe clicking one of the buttons at bottom should also expand the applet if it is collapsed. That would probably make sense. b. is something that's not nice and I encounter constantly myself, too. There's multiple layers there: multiple flickable layers, the whole concept, and also some technical challenges in getting QML to do what one actually wants it to do. I don't have any immediate ides how to make better with current paradigm, though. Although the solution you described at point 1. would make sense especially with Wikipedia and Albums, it's not a behaviour pattern that I'd be quite happy with in my own usage. Some comments on the notes: -- The "current track" and five "similar artists" fit well in one context view tab. -- A tab with only "similar artists" can list more than five (if the user want to customize it as needed) ----> True, but I'm generally very hesitant to changing/removing any existing functionality, as I don't really have a good idea on how people are actually using the context view (but judging from quite various bug reports/feature request, might be pretty diverse usage patterns) -- A tab for "Albums" can show (and edit?) the tracks rating 🟊🟊🟊✩✩, instead of being a duplicate of filtering the library with the current artist name. As of now, if the track is not currently playing, the only possibility to view and edit the rating tag is to open the "Edit Tags" window (right-click on the selected track(s), one track at a time if the ratings are different) -----> Could be, but with Albums applet, there are especially technical hurdles. It's interaction with database and player is a pretty complex beast, and I still haven't managed to work around various small issues that Qt6/QtControls2 port introduced (currently in git master). On the other hand, I'd like to make it easier to create new context view applets. This might contradict with the tab-based view. Somewhat related invent.kde.org issue is also available at https://invent.kde.org/multimedia/amarok/-/issues/12