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
