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

[Tomeu Vizoso]

The idea is that we have a complex system, and that value can be seen
in having this system degrading gracefully when an unexpected error
happens. Even more when is an area where kids are supposed to play
with (adding device icons to the shell).

Adding just one try..except block before gtk.main won't give us this
graceful degradation.

Tomeu

On Tue, Apr 29, 2008 at 2:24 PM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
> I'm not really sure about the value of this kind of try/except blocks.
>  If the target is to avoid the shell exiting in any case, we could as
>  well try/except the whole code executed before gtk.main().
>
>  Marco
>
>
>
>  On Tue, Apr 29, 2008 at 2:12 PM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>  >
>  > On Tue, Apr 29, 2008 at 1:37 AM, Martin Dengler
>  >  <martin at martindengler.com> wrote:
>  >  > 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.
>  >
>  >  I think that Michael has spotted here a wonderful opportunity for
>  >  making Sugar more robust, thanks to your patch.
>  >
>  >  What about just making the shell to catch (and log) any exception
>  >  resulting from the initialization of a device? That should amount to
>  >  just add one try..except block.
>  >
>  >  Devices are thought to be easily added, so its an expected source of
>  >  new bugs. The shell should be able to start when any of them fail.
>  >
>  >  Thanks,
>  >
>  >  Tomeu
>  >
>  >
>
>
> > _______________________________________________
>  >  Sugar mailing list
>  >  Sugar at lists.laptop.org
>  >  http://lists.laptop.org/listinfo/sugar
>  >
>