Bug 468390 - PassiveNotification covers interactive UI elements on the bottom in common mobile UIs/apps
Summary: PassiveNotification covers interactive UI elements on the bottom in common mo...
Status: CONFIRMED
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 5.105.0
Platform: Other Linux
: NOR minor
Target Milestone: Not decided
Assignee: kdelibs bugs
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2023-04-11 13:56 UTC by witchhunter
Modified: 2023-04-12 08:43 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
player_controls_are_not_available (224.33 KB, image/png)
2023-04-11 13:56 UTC, witchhunter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description witchhunter 2023-04-11 13:56:35 UTC
Created attachment 158015 [details]
player_controls_are_not_available

SUMMARY

Within 'tracks' view , when quickly playing available songs, notification "Playlist cleared" is placed right above the playback controls. It is then difficult/impossible to pause the song, so the notification appears misplaced.


SOFTWARE/OS VERSIONS
PinePhonePro Plamo
Manjaro

ADDITIONAL INFORMATION
Possibly relevant   https://bugs.kde.org/show_bug.cgi?id=394575
Comment 1 Nate Graham 2023-04-11 17:39:39 UTC
Can confirm. Not sure how to fix it though, or if it's worth fixing. Options include:
1. In Kirigami, make the initial location of these notifications configurable, then use that feature in Elisa to make them appear higher than the player bar
1. In Kirigami, make the initial location of these notifications automatically higher when in mobile mode, on the assumption that there's probably bottom content we don't want to obscure
3. Use a different kind of notification; something custom in Elisa
4. Move the Player bar somewhere else

3 and 4 seem undesirable, which leaves 1 and 2 as options. Moving to Kirigami, since that's where either of those options would need to be implemented.
Comment 2 witchhunter 2023-04-12 08:43:36 UTC
(In reply to Nate Graham from comment #1)
If I had to choose one of the options from above, I would go with second option. It seems more appropriate since that is the place where information are shown (at least in desktop mode). Hopefully, that would be an easy solution.

Now, I'm not that knowledgeable what the proper solution would be, but I can say what would make it feel natural/expected behavior.
Long_press or drag the song towards right/playlist to enqueue it (the bonus points if the right border highlight for a second), and tap for a quick play; if that's even possible in this Kirigami implementation. This would also eliminate "play now" button in a desktop mode since doubleclick could be used for a quick play.

In case the song needs to be in the playlist for a quick play (if I understood the other post correctly):
1) create a temporary playlist which would include all the new-played songs. 
2) enqueue the song in the current playlist, but highlight them it in the playlist.
Each of this solutions would also reduce the count of popups notification significantly, but would require a user to distinctively save the new/altered playlist (perhaps also highlight the save button).
For further notice: It should go without saying, thanks for improving the mobile experience :)