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

[Martin Dengler]

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