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

[Tomeu Vizoso]

On 5/4/08, Martin Dengler <martin at martindengler.com> wrote:
> 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.

If it's not much work, can you provide a patch that gives an idea of
what you plan to do? No need to be the final patch right now.

Your ideas look interesting but I'm having a bit of difficulty in
visualizing how you would refactor things.

Thanks,

Tomeu