[sugar] [PATCH] Add speaker device and icon by default

[Michael Stone]

On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote:
> On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote:
> > Can calls to self._mixer or self._master fail even when these attributes
> > are not None?
> 
> It doesn't appear a concern from the existing hardwaremanager.py code,
> and not in practice: I've tested checking/changing the volume in a few
> activities.

I seem to recall having encountered situations where sugar startup would
fail (in early versions of the QEMU image, before sound began working)
as a result of unchecked use of sound hardware. I fixed the problem by
commenting out volume control in the sugar shell. It was a particularly
annoying problem because it was persistent, which meant that X entered
an infinite reboot loop.

> The original author of the hardwaremanager.py trusted the gst classes
> just as much as I am...  also keep in mind that I actually saw and
> worked around two failures (#6933, #6934) of exactly these
> attributes/implementations, 

In your opinion, did the original author of hardwaremanager.py (or
authors of the clients of hardwaremanager.py?) exercise the degree of
caution necessary to deliver a solid, reliable Sugar experience to our
present audience? (I say "present" audience because I think that our
audience has changed from one which consisted primarily of developers to
one which consists primarily of semi-literate children.)

> > Also, what happens if an exception is thrown by, say, Device.__init__()?
> 
> Given the current state of error checking, sugar (the shell) will fail
> to start and matchbox will exit (I saw this during testing, and just
> now tried 'raise Exception("we love m_stone")' to confirm.)

Is the exception properly recorded? Is it possible (easy?) to send the
traceback upstream to us?

> Device.__init__() is four lines of code, and depends on
> util.unique_id() and gobject.GObject.__init__().  

Device.__init__() sounds like the sort of thing that I expect will be
overridden by subclasses in interesting ways and it sounds like the sort
of thing that will break when people try to run Sugar on platforms we
haven't tested pre-qualified.

> and no other similar bit of code... does any more checking than this.

Is this good? In particular, is it good that an exception that bubbles
up through Device.__init__() causes X to enter an infinite restart loop?

> And please excuse me if I've missed a howler of a bug that you're
> socraticly/patiently trying to make me realize - just feel free to say
> outright what sucks and I'll fix it!

You seem to be telling me that Sugar will crash if any of its device
abstractions fails to initialize. That seems like a howler of a bug to
me (though perhaps not one in your code). Is this desirable behavior? Is
it intentional?

Thanks for putting up me,

Michael