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

[Martin Dengler]

On Mon, Apr 28, 2008 at 06:12:31PM -0400, Michael Stone wrote:
> 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.

Yes, that problem exists and my patch is no worse in this respect - I
meant to make both points very explicit later in the email to which
you replied.  Given the clear implication that we should do better,
I'll change my patch.

If you, or marco, or anyone has an opinion about where the best place
to introduce the real paranoia, please let me know.  OTTOMH, given we
obviously want to make Sugar not crash and (secondarily) minimize
spamming of 'try:...except's, hardwaremanager.py's where I would
introduce the bulk of the changes (rather than make speaker.py,
randomactivity.py,
presence-palette-that-wants-to-make-a-dinging-noise.py, etc. do this).

If anyone thinks that's controversial let me know.

> > 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.)

As a rhetorical question I think I understand the point.  As a
non-rhetorical question, I'll decline to answer due to lack of
context/familiarity with the conditions.

> > > 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?

I'm sorry, I will have to research the proper way to record such an
exception.  I don't know.

> Is it possible (easy?) to send the traceback upstream to us?

Very interesting idea.  Is there a plan for aggregating such data?
cscott's FISL presenation had some (http-sourced?) usage graphs...is
there a "Send Microsoft a Report"- (or "We Share Your Pain" :)) like
server to which our code could send such reports?  Do you want
automated/staged trac submissions? The design/architecture/maintenance
solution space is well beyond my time to explore.  Lacking any leads
therein I'm going to answer to your question as "I know not this
'upstream', would be happy to use one, but have no resources to build
one".

> > 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.

I think you're encouraging me to make Device.__init__() a bit safer,
or add some comments, or something similar, rather than changing
speaker.py's __init__().  It's going to get a bit hairy if we can't
trust our superclass(es)'s constructor(s).  Or perhaps you'd have me
consider patching devices.py, to survive any of its devices' not
initializing.

If you / anyone has a preference for either approach, or how I
structure the changes into one or more patches (this is part of the
culture that I haven't picked up yet), please let me know.

Otherwise I will go forward with what you've said on the principle
that you/others would rather slap my code back/down than micromanage
me forward.

> > 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?

ibid.

> > 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?

No, and (from the point of view of a non-Sugar, non-OLPC, new patcher)
I had to consider that it was intentional, or at least was something
that (before your email) I wasn't in a position to presume to change
(or to submit a patch that invasive for a new icon addition).

I'm happy to revise that approach, as hopefully previously made clear.

> Michael

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/sugar/attachments/20080429/58e24668/attachment.pgp