[amarok] [Bug 502490] Each applet should get the full context view space (in its own "tab")

2026-05-13 Thread Tuomas Nurmi
https://bugs.kde.org/show_bug.cgi?id=502490

--- Comment #3 from Tuomas Nurmi  ---
Context applet sizes not getting saved has actually already been fixed (
https://bugs.kde.org/show_bug.cgi?id=514190 ) but there hasn't been an actual
release with the fix included yet. I've been planning to do one in May, but on
the other hand, I'd like to accumulate some more fixes first.

-- 
You are receiving this mail because:
You are watching all bug changes.

[amarok] [Bug 502490] Each applet should get the full context view space (in its own "tab")

2026-05-13 Thread Arek Guzinski
https://bugs.kde.org/show_bug.cgi?id=502490

Arek Guzinski  changed:

   What|Removed |Added

 CC||[email protected]

--- Comment #2 from Arek Guzinski  ---
> 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.

Maybe some arrows up and down on the center of the line (like the mouse cursor
when you're above something you can drag to resize) would work.
But more important: It would be great if the widgets would remember their new
size.


>> 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).
> 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.

And Lyrics. My suggestion: add an option to these widgets that causes them to
stretch across all remaining space.

-- 
You are receiving this mail because:
You are watching all bug changes.

[amarok] [Bug 502490] Each applet should get the full context view space (in its own "tab")

2025-04-08 Thread Tuomas Nurmi
https://bugs.kde.org/show_bug.cgi?id=502490

Tuomas Nurmi  changed:

   What|Removed |Added

 CC||[email protected]

--- Comment #1 from Tuomas Nurmi  ---
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

-- 
You are receiving this mail because:
You are watching all bug changes.