The Great Pulseaudio Mixer Debate: a modest (productive) proposal

Michael Cronenworth mike at cchtml.com
Fri Apr 24 18:19:40 UTC 2009


-------- Original Message --------
Subject: The Great Pulseaudio Mixer Debate: a modest (productive) proposal
From: Adam Williamson <awilliam at redhat.com>
To: fedora-devel-list at redhat.com
Date: 04/24/2009 01:03 PM

> So, in the spirit of light rather than heat, here's my proposal, again,
> rescued from the depths of the flamefest, with some actual work
> attached.
> 
> g-v-c is clearly intending to be an abstracted and simplified volume
> control app / applet to cover the most common use cases in a friendly
> way. Great.
> 
> It's clear, though, that some users have needs beyond this, which are
> likely only going to be satisfied in a sensible way by access direct to
> the ALSA mixer elements. Bastien and Lennart don't want some kind of
> hack to expose these via g-v-c, and I'd tend to agree, that's clearly
> not what it's designed for.
> 
> So my proposal is that we include by default an alternative GUI app
> which allows direct access to the mixer channels.

Forget about a second app. I'm doing that now in F10. pavucontrol and 
g-v-c. I don't want to keep having to use two. This is 2009. We have 
quad-core 64-bit computers with 16 gigs of RAM and 2 terrabyte hard 
drives. Lets put our computers to use instead of being lazy.

I understand we want to make Linux for the Desktop easy to use and all, 
but why force simple GUI elements on everyone?

Is it too much to ask for a "advanced" checkbox that toggles the display 
of extra widgets? You can bury this away in a Preferences menu, or heck, 
even hidden only in gconf.

Making things easier to use is great -- but restricting UIs to only have 
an "easy mode" 100% of the time isn't for everyone. Saying "no" to calls 
for change to the UI isn't helpful either. If g-v-c, or on a bigger 
scope, Gnome, was being developed by a business the developers would 
have been fired long ago for their arrogant ways.




More information about the fedora-devel-list mailing list