23 comments

[ 3.4 ms ] story [ 61.1 ms ] thread
No one in the attached thread even mentioned the fact that volume settings should increment in decibels, not percentages. One decibel is a volume change so small as to be just perceptible to a typical human observer. The other advantage of a decibel scale is that it increases exponentially, each step one decibel, which means there are fewer total steps in a typical volume control range than if percentages are used.
Lets get real here! Just because they didn't fix your favourite bug does not mean the whole project sucks.

The maintainer isn't interested in making it configurable (and from reading the thread, I agree, it just moves the problem elsewhere) and there has to be another way to fix it. I am sure the maintainer would be reasonable about accepting a different solution.

Be the change you seek - get annoyed, fork the repo, apply a fix and propose a patch.

EDIT: The issue appears to be open and not marked as won't fix.

The maintainer isn't interested in making it configurable (and from reading the thread, I agree, it just moves the problem elsewhere)

Since I started using Linux, I've constantly bumped up against problems in other operating systems where I've wanted to take control of a particular tiny niggling detail and make that decision myself. Linux has consistently allowed me to do that, with a plethora of hidden configuration settings.

Put simply, the design philosophy of many features of Linux distributions and environments allows me to decide what I want my system to do. Sure, it's moving the problem elsewhere, but it puts the solution to that problem in my hands. If I want 2% step, then it's my problem if that's too many steps. If I want 15%, then it's my problem if it's too large a jump. Either way, it's my decision and I can't complain if it's my configuration.

Gnome 3 removed a lot of my ability to screw up my own system in ways that make me happy. This decision is typical of that philosophy (for better or for worse) and is another incremental design decision that keeps me from using Gnome 3.

There are dozens of options on Linux for people who love to tweak every little detail of the setup, do we really need yet another one? I for one am glad someone is trying, for better or worse, a different approach, if only to see how it might work out.

In fact I'd love to see Gnome 3 go even further and go from being 'just' a desktop environment to a fully fledged Linux based desktop operating system, dictating the whole stack from kernel and file system on up. I imagine there are some pretty cool things you can try on the desktop level if you can exercise that sort of control.

I think we can see how it's working out. Badly.
There are dozens of options on Linux for people who love to tweak every little detail of the setup

Only dozens? I've over 16000 files ending in rc, cnf, conf, cfg, ini, config, and that's not counting additional compile-time configurations available to me. A quick sampling of those files shows that many of them contain 10-20 options.

do we really need yet another one

Depends who "we" is. The people in OP's linked thread clearly do. I haven't touched the vast majority of the thousands of options available to me, because I'm happy with the defaults. My definition of "user-friendly" includes super-technical users who want to fine-tune their system to their needs. Fortunately, my system allows me to do that for most settings I feel competent and opinionated enough to change.

Only dozens?

I mean dozens of desktop options, not dozens of config options.

If configuring all those things is important to you, then perhaps Gnome 3 is not for you, and that's totally OK. You even admit to not using Gnome 3 and have found something that works better. Not all desktops need to have the same design philosophy, in fact I think it's a good thing that they don't.

Only dozens? I've over 16000 files ending in rc, cnf, conf, cfg, ini, config,

With all due respect I have to say "bullshit." What command did you use to come up with that figure?

    root@ronin:/tmp# tree -ifa / > /tmp/hn.bs
    root@ronin:/tmp# cat hn.bs |grep -v src\$ |grep -v /bin/ |grep  -v -- "-"\>|grep -vi backup | grep -v dfc/linux-kernel |grep -v /samurai | wc
    2513    2540  128342
That is just a cursory attempt to eliminate false positives.
Even with your more rigorous method than my handwavey one, I think it's fair to say you made my point even more than I did ;)

(substitute "16000" in my post with "2513" from yours, and see if it changes my meaning one iota).

I think it makes your argument seem disingenuous and that certainly does not help make your point.
different strokes for different folks. This is exactly why i've been using gnome 3
Fork it, patch it and provide your own package if you really want the extra options.

I did it with network manager for years due to shitty acmel wifi driver timing issues and when the drivers got fixed I stopped using my patches.

No one will stop you patching. The maintainer is doing the, well, maintainable thing - saying no to something that shouldn't be the job of the software at that level.

No, but a consistent policy of ideology over pragmatics probably is reason enough to say that a project "sucks". The saying goes, "Don't let the perfect be the enemy of the good." GNOME as a whole has precisely the opposite take on things, even when consistently the perfect doesn't yet exist. Seemingly every decision is coming down to someone saying "the right thing to do is for the system to just know what the user should want with no input required from them", which might be an admirable goal, but one that's not attainable, and the second best option isn't "have the system do something no one wants with no input required from them."
"As per discussion earlier in the bug. I'm not making this configurable. Please find a way to use dB information from the sound card to provide a decent default. Swapping a hard-coded number for another one isn't going to fix it, and neither is a hidden configuration option." [1]

Didn't a number of people say that the sound card can't always give the dB levels?

1. https://bugzilla.gnome.org/show_bug.cgi?id=650371#c43

Exactly; and for all intents and purposes this amounts to a wont-fix, although it is still marked as "new".
I think that shows why Gnome 3 is good. They won't add another knob if that needs tweaking. Somebody needs to fix the actual problem. Sounds to me like there is an issue with the settings of some sound cards. If you sound card can make your amp cut out a 6% then I don't think that is a software problem. Like Network manager before it I think a lot of the sound problems point back to drivers or hardware not reporting back correctly. This probably needs to be tackled there.
Sure. Clearly the best solution is one that addresses the actual problem, which is below the level of the UI.

However, in conjunction with that (or indeed, in the absence of that, which is the current situation) the optimal solution is a sensible default, along with user-configurable differences for those users who have some opinion and technical acumen to use them.

This has been the design philosophy of Linux applications and environments for a very long time, but for some reason is against the wishes of the Gnome 3 team.

So not even a workaround whilst someone works on a fix? Has been two years. And wasn't it pointed out that the sound card won't always know the dB level?
This is not a driver problem, nor a case of hardware not reporting back correctly. The decibel information is not available in many sound setups. And it's never going to be available for these setups.

Even for setups where decibel information can be gathered / estimated by the sound card, why should the volume increment be hard-coded? Shouldn't the user get to decide that?

Also note that this setting was available in GNOME 2. Remove existing functionality without providing an alternate doesn't make sense to me, given that it is a potential health hazard!

So this thread is going to turn into a 'Blame Lennart' thread in 3, 2, 1 ...

(Cue "And now he's destroying the Unix Way™ with systemd" and '"Pulseaudio ruined every installation I've ever made, it's the first thing to remove" whining)

Gnome isn't favored around here, I get that. But random (yes, random to me. I consider that bug irrelevant) 'the project sucks' headlines? That's really low. Flagged.

Edit: Slighty more constructive:

    pactl set-sink-volume 0 +5%

    pactl set-sink-volume 0 -- -5%
There. Bind that to whatever keys/situations/occasions you'd like, replace the 5 with any other arbitrary number that feels better. Done. "Hazard" avoided.
Thanks for the pactl tip. I was not aware of it.

I am not saying the problem is un-surmountable. And it is not just me I am concerned about. Every person that I introduce to linux (via Ubuntu) is going to face this problem. A simple setting could save many hours and ears.

I used "sucks" for the whole project because of many such dumbed-down decisions that have been made in GNOME3. This one was just the last straw for me. I could have probably avoided the word though.