[sugar] [PATCH] Add speaker device and icon by default
Martin Dengler
martin
Sun May 4 10:29:03 EDT 2008
On Tue, Apr 29, 2008 at 02:12:58PM +0200, Tomeu Vizoso wrote:
> 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.
I haven't forgotten this thread, just been unable to work on it.
After an hour of messing about with some ideas/code today, my current
approach is a bit more involved than just a try/except but nothing too
dramatic (just a small yak to shave):
- refactor sugar/model/devices/device{,smodel}.py to make
adding/removing device.Device subclasses safe
... this begs one to do the next step or be left with many many
try/excepts and very ugly code (or just one try/except around
speaker.py, which kind of doesn't improve matters that much - though
it's very simple code and I'm happy to move on to other things if
people would accept that :) )
- refactor sugar/model/devices/device{,semodel}.py to make discovering
device python files safe using metaclasses (see
http://blogs.gnome.org/jamesh/2008/02/12/python-metaclasses/ ); I
have considered the objections and alternatives including martian,
Zope's plugin framework design, and settled on this approach because
it's very simple, meets the very simple needs we have, and is very
little code
...this requires one to remove the networkmanager- and
halmanager-specific logic in devicesmodel.py:
- create a new networkmanager model class that will add_device() and
remove_device() using the same logic that used to be in
devicesmodel.py
- create a new halmanager model class in the same way
...and then we only need to:
- trivially update battery.py and speaker.py
- pretty trivially update network/mesh.py, wired.py, wireless.py;
these are only slightly more than trivial because devicesmodel.py
used to define some very network-specific variables that (IMO)
should be exposed by the networkmanager model (above) instead
This explanation is long-winded only because I wanted to allow people
to poke holes in the approach, not because it's a lot of work.
> Thanks,
>
> Tomeu
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/20080504/5d85db30/attachment.pgp
More information about the Sugar-devel
mailing list