Re: FESCo Meeting Summary for 20090424

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2009-05-02 at 00:38 +0100, Matthew Garrett wrote:
> On Fri, May 01, 2009 at 09:37:34AM -0700, Adam Williamson wrote:
> 
> > That doesn't explain why it shipped alongside gnome-volume-control for
> > the last three releases, when all along you have been telling us that
> > shipping two graphical volume control utilities by default is a terrible
> > idea that will confuse people and is bad UI.
> 
> You appear to be arguing on the assumption that people never make 
> mistakes.

Doing something you say is a fundamental interface booboo for three
straight releases is a pretty big mistake. I don't believe this was a
mistake, I believe it was intentional - we want to ship the shiny new
Pulse stuff. And that's fine. It just means the arbitrary "no multiple
mixers" argument that's now being used to oppose gst-mixer /
gnome-alsamixer is an argument of convenience.

> > And, I really should have anticipated your reaction. Of *course* the
> > correct response to me pointing out that we're already shipping two
> > volume control applications by default and have been for a while with no
> > apparent problems is not to accept that this means it's probably a
> > perfectly good idea to have multiple applications so long as they each
> > expose important functionality that the other doesn't. No, the correct
> > response is to say that we should immediately drop one to maintain
> > ideological purity.
> 
> How many volume control applications do you want us to ship with? The 
> fact that mistakes have been made in the past is not an argument for 
> further mistakes being made in the future.

Frankly, now I've noticed we *already* have two, I'm inclined to favour
the "drop the new gnome-volume-control entirely" argument, if you want
to keep the number of mixers down. Here's the problem. There are two
really important use cases that gnome-volume-control doesn't cover:
profile switching - i.e. enabling digital output (or analog surround on
cards that do that, but that's not *so* important), and input switching.

Legacy mixers - gnome-alsamixer / gst-mixer - handle both of these cases
and everything else you'd want to do with a mixer. Just not very well,
but hey, at least it's the same crappy interface people have been used
to for a decade.

pavucontrol does profile switching, and does it in a very nice way,
thanks to the work done on Pulse during this cycle. But it doesn't do
input switching.

gnome-volume-control doesn't do profile switching *or* input switching.

So the only mixers we have that actually cover these really basic use
cases are the legacy ones. If you're completely wedded to the new g-v-c,
but we want people to be able to do input switching and use digital
output, we'd need at least two mixers: g-v-c and a legacy mixer. But
then we lose pavucontrol's nice profile switching, which is a bit of a
shame.

Frankly, the combination that appears to combine the most actual
usability with PulseAudio niceness is pavucontrol + a legacy mixer.
g-v-c, in functional terms, has exactly no advantages over either
pavucontrol or the legacy mixers. Its *only* advantage is that it's a
more standard-following GNOME interface than pavucontrol. Whoopee. I
don't think that outweighs the fact that it's missing two really
important features. I've been ignoring digital output throughout this
whole debate because Lennart had argued me out of that one in the
initial bug report I filed, but I forgot that his argument depended on
pavucontrol.

Summary: legacy mixers do everything with a crap interface, pavucontrol
does everything except one big thing with a quite nice interface, g-v-c
misses two big things and has a marginally nicer interface than
pavucontrol. Given that, my opinion is that the options "pavucontrol +
legacy mixer" or just "legacy mixer alone" are tied in niceness, and any
combination involving the new g-v-c falls rather near the bottom of the
pile...

> > I mean...sheesh. Are you serious? We should drop pavucontrol because
> > including it is an 'oversight'? Despite the fact that, as I pointed out,
> > gnome-volume-control has no profile support and hence you can only use
> > pavucontrol to switch from analog to digital output, or from analog
> > stereo to analog surround? And even *Lennart* advocates using it this
> > way, in various bug reports?
> >
> > Presumably none of your 'target users' has an S/PDIF output either? Or
> > an analog surround sound setup?
> > 
> > This is just getting ridiculous.
> 
> At this point? My personal feeling is that you're being needlessly 
> hostile and appear to be assuming the worst of the desktop people. Can 
> we get back to discussing this rationally rather than simply making 
> observations and turning them into assertions?

I'd love to be discussing it rationally, but I don't think you guys are.
I still haven't seen a convincing refutation of the "we already have
multiple mixers" point besides "it's a mistake" - which, even if it's
true, makes you guys look rather bad, as it's a fairly large mistake (by
your own standards) in three straight stable releases...which doesn't
actually seem to have caused any problems, I certainly haven't seen
anyone complaining that the presence of pavucontrol alongside
gnome-volume-control confused them, in F8, F9, or F10. Where does that
leave the "multiple mixers are bad by definition" argument? Even if it
*was* a mistake, the fact that it's been in the distro for three
releases without apparently causing any trainwrecks seems rather
significant to me.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux