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

[Martin Dengler]

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.

The original author of the hardwaremanager.py trusted the gst classes
just as much as I am, though I wouldn't want to hide behind that; if
you're concerned I haven't done enough research about these APIs (I
love abusing abstraction and limited documentation in a language
without checked exceptions to write code fast:)), well, that's
understandable (though I have done some research on GstElement[1,2],
GstState[3], and the anemic state of python-gst documentation (could
be a sign of great code :))[4,5] and I think it's OK enough for me).

Also keep in mind that I actually saw and worked around two failures
(#6933, #6934) of exactly these attributes/implementations, so if your
concern is that they'll DoS/make Sugar more fragile, I'm happy to add
a bit more paranoia to hardwaremanager.py - so far I just have the
existing code to guide me as to what level of paranoia is justified,
but as you're the one paid to be paranoid :) I of course would not
object to being corrected / directed differently.

Can you explain a bit more about your concern(s) so I can address them
better?

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

Device.__init__() is four lines of code, and depends on
util.unique_id() and gobject.GObject.__init__().  I'm no expert on
those two, but that seems trivial/robust enough to not wrap in a
try/except, and no other similar bit of code (battery.py,
network/*.py) that depends on Device.__init__() and has the same
exposure to its behavior does any more checking than this.

Again, can you explain a bit more about your concern(s) - e.g., would
you prefer a try/except in speaker.py, or device.py, or something
else?  Or were you just curious as to the likelihood of
failure/complexity of Device.__init__()?

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!

> Thanks,
> 
> Michael

Martin

1. http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElementFactory.html#gst-element-factory-make

2. http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElement.html

3. http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElement.html#GstState

4. The example for interacting with the mixer:
http://webcvs.freedesktop.org/gstreamer/gst-python/examples/mixer.py?revision=1.2&view=markup
. Of course it's an example and it's got about 4 PEP 008 style
violations that smacked me on the head, but the last commit is an
attempt to make it not grossly fail under some normal error condition
so it's at least a minimum bar of how to interact with the mixer,
which it seems hardwaremanager.py vaults easily, before and after my
patch :).

5. http://www.jonobacon.org/?p=750 <-- this is the author of
python-gst, it seems, complaining about the lack of documentation but
doing a really good job of starting to rectify the situation :)

-------------- 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/20080428/abe74dd2/attachment.pgp