D20569: RFC: Use more compact OSD

[Mélanie Chauvel]

achauvel added a comment.


  Several options were discussed here, and I have a few questions:
  
  Do we want to keep the current design?
  --------------------------------------
  
  I don’t really understand why the OSD has to be so huge, because it contains so few information compared to a notification:
  
  - It’s triggered by the user so it’s not a big event that should distract (could be a big deal with attention disorder) or be specially put forward to the user (it should only be a confirmation of what’s happening)
  - Only a short sight is necessary to understand what’s happening because it’s only telling a change between:
    - an on/off state (e.g. mute/unmute sound or microphone)
    - a choice in a limited list (e.g. keyboard layout)
    - an increase or decrease of a value (e.g. sound or brightness)
  - Things appearing on-screen should (in my opinion) try to not cover what’s the user is working on (e.g. changing the music’s volume should not hide what the user is working on)
  
  If we want to keep the current design, how should we handle the switch between compact and large OSD? (I would personally prefer compact OSD at all time)
  
  Should it use the notification system?
  --------------------------------------
  
  I don’t think I know any platform with a unified notification/OSD system (at least it’s not the case on Windows, macOS, Android, and GNOME Shell). Also, it’s not straightforward because we may want OSD to continue behaving differently than notifications, so it may actually be counter-productive in terms of code complexity etc. (and obviously this would be a much larger change than an alternative compact layout and/or place on screen for OSD) So except if we have a strong case for unifying notifications and OSD, I don’t think it’s something we should do.
  
  How to configure it?
  --------------------
  
  We might want two things: compact OSD, and be able to put it where we want (because people have different layouts of panel, Krunner in a different place, etc.).
  
  - There could several options for e.g.: large mode/compact mode/automatic (= large usually, compact in fullscreen).
  - There are already several places where we could chose a place on the screen or a screen edge: kcm_notifications, kwinscreenedges and kwintouchscreen. This might not be a big deal to have another screen like that for OSD.
  
  What do we agree on?
  --------------------
  
  So this comment is mostly my views on the issue, and if we want to go forward with this, we have to agree on whether and how we want to do it.
  
  Note: I’m using a hack found on Reddit <https://www.reddit.com/r/kde/comments/9j57z2/fixing_the_awful_volumebrightness_osd_size/> and I’ve noticed the sound OSD reports a different value than the applet, because it doesn’t take into account that the sound maximum value might be more than 100% (e.g. applets reports 50%, OSD reports 33; applets reports 150%, OSD reports 100). This is not a problem with the current design because it doesn’t display any value (only a bar), but this needs to be taken into account for a compact version displaying a number.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D20569

To: broulik, #plasma, #vdg
Cc: kori, Armstrong, alexde, achauvel, abetts, ngraham, davidedmundson, hein, Codezela, Fuchs, filipf, zzag, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20200428/9eddea1c/attachment.html>