[sugar] [PATCH] Add speaker device and icon by default
Tomeu Vizoso
tomeu at tomeuvizoso.net
Tue May 6 10:39:30 EDT 2008
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
More information about the Sugar
mailing list