Add option for whether to show the volume change OSD
Needs ReviewPublic

Authored by anonym on Aug 20 2018, 1:04 PM.

Details

Reviewers
None
Group Reviewers
VDG
Summary

When watching movies with significant volume differences (i.e. most modern movies) I find myself adjusting the volume a whole lot. Since the volume OSD appears in the middle of the screen I also have to rewind the video. That's just too disruptive (#347123 was not enough), so let's make it possible to disable the OSD completely.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
anonym created this revision.Aug 20 2018, 1:04 PM
Restricted Application added a project: Plasma. · View Herald TranscriptAug 20 2018, 1:04 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
anonym requested review of this revision.Aug 20 2018, 1:04 PM
broulik added inline comments.
applet/contents/config/main.xml
15

You cannot rename that existing key as it would reset every user to the default value then as it would read from a new key

broulik added a reviewer: VDG.Aug 20 2018, 1:27 PM
anonym updated this revision to Diff 40053.Aug 20 2018, 1:54 PM

Got it! I changed:

  • volumeAudioFeedbackvolumeFeedback (like before)
  • volumeOsdFeedbackvolumeOsd

Ok?

mart added a subscriber: mart.Aug 21 2018, 9:18 AM

this begs more the question whether the osd layer should stay on top of fullscreen windows, rater than adding yet another configuration option

this begs more the question whether the osd layer should stay on top of fullscreen windows

It used to not do that but people also complained (me included, I want it ontop of my video). Maybe we need a new, more compact design (like the bar we had in 4.x), or one in the top left rather than center like Windows 10 has these days.

Could we have a small bar at the top edge of the screen in case of fullscreen app and otherwise the current one?

I think the current UI is just fine as the default; no need to change it. Simply making it smaller wouldn't really help the submitter's use case very much anyway since it would still show up and cover up something. However I'd be open to making the default appearance configurable, as a small but vocal cohort of people don't seem to like it.

That's material for another patch though.

Simply making it smaller wouldn't really help the submitter's use case very much anyway since it would still show up and cover up something.

Yes; I would be completely happy if the current (size and all) OSD would appear in the periphery of the screen, preferably a corner. So perhaps the missing option is actually a drop-down for the position of the OSD? An ambitious plan would be:

  • Center: the current OSD. (Default)
  • Notification Area: shows a thin vertical bar in the Notification Area (so the lower right corner for the default panel).
  • Top: shows a very thin horizontal bar centered at the top edge.
  • Bottom: like the above.

However I'd be open to making the default appearance configurable, as a small but vocal cohort of people don't seem to like it.

Yay! I was trying to not just be another voice by providing an actual patch, but...

That's material for another patch though.

...I won't commit to dig deeper into the OSD subsystem, which this would require.

Yes; I would be completely happy if the current (size and all) OSD would appear in the periphery of the screen, preferably a corner. So perhaps the missing option is actually a drop-down for the position of the OSD? An ambitious plan would be:

  • Center: the current OSD. (Default)
  • Notification Area: shows a thin vertical bar in the Notification Area (so the lower right corner for the default panel).
  • Top: shows a very thin horizontal bar centered at the top edge.
  • Bottom: like the above.

I just stumbled upon this reddit thread with a significant number of upvotes: https://www.reddit.com/r/kde/comments/9j57z2/fixing_the_awful_volumebrightness_osd_size/

So I guess it's an idea worth pushing forward. :)

Yeah, I saw that too.

I'm still against an option to hide it entirely, but I could get behind an option to show a more compact version.

I could also support moving all of the square-style OSDs farther down so they're not as close to the center of the screen.

Please don't introduce options based on what's unpopular on Reddit.

svenmauch added a comment.EditedOct 2 2018, 12:54 PM

Please don't introduce options based on what's unpopular on Reddit.

I'm not suggesting we should base new options entirely off reddit opinions. That would be short-sighted. :)

However I see no harm in adding to this discussion that changes or new options to OSD would be welcomed by a number of people. Certainly falls under the category "quick and dirty user research" but then again, why disregard it completely?

From what I gathered so far there is a need (more or less) for a less obstrusive and a completely hidden OSD. I'd get behind three options so we don't overcomplicate things: classic, compact, none.

Of course I'm open to arguments why we shouldn't do this. :)

Listening to user feedback is important. We not only have complaints on Reddit, but also someone was motivated enough to submit a patch here. I've also seen it brought up in Bugzilla tickets.

It's not about that there are only complaints on Reddit. It's about the user group: do we want to deaign so that the small Reddit community is happy or do we want to design for the rest? Do we want to make the product more complicated (yes that's the result of a config option) to please some people on Reddit while at the same time we already have a mechanism to achieve the same?

rooty added a subscriber: rooty.Oct 3 2018, 6:44 AM

Please don't introduce options based on what's unpopular on Reddit.

I'm not suggesting we should base new options entirely off reddit opinions. That would be short-sighted. :)

However I see no harm in adding to this discussion that changes or new options to OSD would be welcomed by a number of people. Certainly falls under the category "quick and dirty user research" but then again, why disregard it completely?

From what I gathered so far there is a need (more or less) for a less obstrusive and a completely hidden OSD. I'd get behind three options so we don't overcomplicate things: classic, compact, none.

Of course I'm open to arguments why we shouldn't do this. :)

offer the option to obscure/hide the OSD, but I personally like the full screen OSD so i'd prefer to have the option to keep it

rooty added a comment.Oct 3 2018, 6:46 AM

I could also support moving all of the square-style OSDs farther down so they're not as close to the center of the screen.

why?

filipf added a subscriber: filipf.EditedOct 3 2018, 7:09 AM

What would be the problem in having both the option to turn the OSD off and having the option to change its appearance?

The plasma-pa settings dialog is super uncluttered right now so I don't understand the argument that it would complicate things.

As for the default appearance of the OSD, I believe it's fine. If you move it down, you're sort of obfuscating less of the action in the video, but you're now also potentially blocking the user's subtitles, which is IMO worse than superimposing oneself over the video.

EDIT: Visual proof that we shouldn't be lowering the position of the OSD (and some people even have bigger subtitles than I do)

anonym added a comment.EditedOct 3 2018, 3:46 PM

It's about the user group: do we want to deaign so that the small Reddit community is happy or do we want to design for the rest?

For what it's worth: I opened this ticket and sent the patch, and I am not part of the Reddit community. Before I implemented my own fix I searched around for a solution I encountered a plethora of complaints and patches, with Reddit just being a drop in an ocean:

Do we want to make the product more complicated (yes that's the result of a config option) to please some people on Reddit while at the same time we already have a mechanism to achieve the same?

What is this "mechanism" you are talking about? I'm intrigued!

What is this "mechanism" you are talking about? I'm intrigued!

We have a mechanism for theme providers to change the OSD. (the whole LNF package stuff). They can override all qml, that qml does the positioning.

The recurring pattern that we want to avoid is having a framework where theme creators can set everything, whilst simultaneously the default theme becomes itself a theme engine itself by having a billion options.

filipf added a comment.Oct 3 2018, 5:33 PM

The position that current state is the one and only way really puzzles me if I'm trying to look at it rationally.

Personally, I'm actually fine with they way things are and would probably not change much in my config, but I believe the following two arguments have merit:

  1. the square OSDs inefficiently consume space -> they just seem like copying macOS; Windows is more efficient (and more informative since it provides values as well) ... someone should correct me if I'm wrong, but the only reason I see for having them be that big is maybe if you're far away from the screen, otherwise the user could easily tell they're affecting e.g. audio even if the icon was many times smaller.
  1. the OSDs do sometimes get in the way while in full screen apps -> gaming and watching videos being the most common actions where you may not want any OSD interference; side-note: the OSDs are big and ugly when running older games which do not support your screen resolution

I think these are legitimate issues regardless of whether or not there has been talk about it on Reddit or elsewhere and I do not think addressing them should be seen as catering to a small group of users, but instead as following through on KDE's philosophy. Those that are okay with the defaults just use the defaults, however, Plasma is meant to be powerful when needed. On a practical and comparative level the user can already change the panel location and size, the location of notifications and so many other things... why must OSDs be a non-configurable thing then?

filipf added a comment.EditedOct 3 2018, 5:55 PM

What is this "mechanism" you are talking about? I'm intrigued!

We have a mechanism for theme providers to change the OSD. (the whole LNF package stuff). They can override all qml, that qml does the positioning.

The recurring pattern that we want to avoid is having a framework where theme creators can set everything, whilst simultaneously the default theme becomes itself a theme engine itself by having a billion options.

Putting the responsibility on theme creators is not a sure-shot way to address things because they usually change a lot more than just OSDs. This means if the user simply wants to address particular concerns regarding OSDs, they also have to go along with the new theme's entire design vision (which is not necessarily always great). So this is in certain cases actually a worse solution than, say, getting a very specific extension in GNOME. Of course though, I do agree there should be a line where one customization option would be too much, I just don't think it applies here - both due to legitimate concerns I tried to touch on in my previous post and both due to the fact that plasma-pa settings are really not at all exhaustive as is (edit: the battery widget options even less and that's an understatement).

The recurring pattern that we want to avoid is having a framework where theme creators can set everything, whilst simultaneously the default theme becomes itself a theme engine itself by having a billion options.

Is this a solvable problem?

A theme with no options doesn't work unless the entire meta-theme is split up into dozens of individually themable components like we do with the lock and login screens, color scheme, etc. So we would need to create the concept of an "OSD theme." But note that some of these sub-themes are themselves configurable: for example you can change the size of the cursor selected by the current cursor theme, or change just the text color of the active color theme.

If, in the interest of pushing everything onto theme creators, we decided to change this and make themes non-editable, the result would be an enormous profusion of themes that are essentially forks of the Breeze version, but with very minor subtle differences from one another. It would be a huge irritation for people who just want to change one or two little things, and searching through and managing all the themes would become a nightmare. Also, most wouldn't be maintained over time as theme creators lose interest, meaning that store.kde.org would become a graveyard of dead themes--even more than it already is today. On the other hand, if we removed the concept of color themes entirely and just kept the individual editability of the colors in the KCM, we'd be losing the ability to easily switch between color themes and download new ones.

In all practicality, we will never have themes with no options or just options with no themes--and we probably shouldn't try to get to either place, because we wouldn't like the result. So I suspect that a firm separation between themes and options is going to prove elusive forever. It's inherently nebulous, and we will not be able to draw a hard boundary between one and the other, similar to how it's often hard to tell where one cloud ends and another one begins. We can only embrace nebulosity; attempts to nail it down will not succeed.

rooty added a comment.Oct 3 2018, 6:20 PM

The recurring pattern that we want to avoid is having a framework where theme creators can set everything, whilst simultaneously the default theme becomes itself a theme engine itself by having a billion options.

Is this a solvable problem?

A theme with no options doesn't work unless the entire meta-theme is split up into dozens of individually themable components like we do with the lock and login screens, color scheme, etc. So we would need to create the concept of an "OSD theme." But note that some of these sub-themes are themselves configurable: for example you can change the size of the cursor selected by the current cursor theme, or change just the text color of the active color theme.

If, in the interest of pushing everything onto theme creators, we decided to change this and make themes non-editable, the result would be an enormous profusion of themes that are essentially forks of the Breeze version, but with very minor subtle differences from one another. It would be a huge irritation for people who just want to change one or two little things, and searching through and managing all the themes would become a nightmare. Also, most wouldn't be maintained over time as theme creators lose interest, meaning that store.kde.org would become a graveyard of dead themes--even more than it already is today. On the other hand, if we removed the concept of color themes entirely and just kept the individual editability of the colors in the KCM, we'd be losing the ability to easily switch between color themes and download new ones.

In all practicality, we will never have themes with no options or just options with no themes--and we probably shouldn't try to get to either place, because we wouldn't like the result. So I suspect that a firm separation between themes and options is going to prove elusive forever. It's inherently nebulous, and we will not be able to draw a hard boundary between one and the other, similar to how it's often hard to tell where one cloud ends and another one begins. We can only embrace nebulosity; attempts to nail it down will not succeed.

agreed

On a sidenote, I think it's worth pointing out that anonym's change pertaining to the name of the "Volume Feedback" option may be good idea because I don't think that term is self-explanatory; I don't think a first-time fiddler necessarily understands what it's supposed to mean.

amaiga added a subscriber: amaiga.Oct 27 2018, 11:06 AM

Yes! Please.
I also struggle to understand what is the rationale for having something this big in the middle of the screen. Its not only distracting when watching movies playing games etc, but also while writing a report or just while basically doing anything that involves watching/reading the screen while listening to whatever in the background.

The real question is: why does the icon need to be this big? Why was the middle of the screen chosen as the only sensible and non configurable position to place the OSD?

mart added a comment.Nov 23 2018, 2:40 PM

I think the current UI is just fine as the default; no need to change it. Simply making it smaller wouldn't really help the submitter's use case very much anyway since it would still show up and cover up something. However I'd be open to making the default appearance configurable, as a small but vocal cohort of people don't seem to like it.

That's material for another patch though.

they can do it: they can do a look and feel package which replaces the osd.

mart added a comment.Nov 23 2018, 2:41 PM

It's not about that there are only complaints on Reddit. It's about the user group: do we want to deaign so that the small Reddit community is happy or do we want to design for the rest? Do we want to make the product more complicated (yes that's the result of a config option) to please some people on Reddit while at the same time we already have a mechanism to achieve the same?

^^^ this, a thousand times this :D

In D14949#364818, @mart wrote:

I think the current UI is just fine as the default; no need to change it. Simply making it smaller wouldn't really help the submitter's use case very much anyway since it would still show up and cover up something. However I'd be open to making the default appearance configurable, as a small but vocal cohort of people don't seem to like it.

That's material for another patch though.

they can do it: they can do a look and feel package which replaces the osd.

But that replaces everything else too. Look-and-feel packages aren't a great solution to the problem of wanting to change only one or two things, and conceptually, they don't scale at all.