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

Martin Dengler martin
Tue May 6 12:40:30 EDT 2008

On Tue, May 06, 2008 at 04:39:30PM +0200, Tomeu Vizoso wrote:
> 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.
> > 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.

This is not a patch because I think it's easier to read due to the
volume of refactoring, and it's very very much incomplete and
unpolished (as I said it's an hour's work), but if you look at them in
order you'll get an idea of what I'm trying, hopefully:

http://pastebin.be/11020 - devicesmodel.py - note this is refactored
to be much simpler, and the major *new* feature is simply the
metaclass usage (I still have to make it import everything in the
model.devices subtree, but you see where it's going)

http://pastebin.be/11021 - device.py - again, much simpler now and the
main changes are 1) register with the metaclass; and 2) subclassers
shoudl implement realize() rather than __init__() to do the real work

http://pastebin.be/11022 - battery.py - example of the changes; they
are basically trivial (superclass, move __init__() to realize(), call
super in realize())

http://pastebin.be/11023 - networkmanagermodel.py - this is where a
lot of devicesmodel.py has gone, because this is really a "meta
device" that creates new devices.Device subclasses as NM tells us
about device appearance/disappearance.  This is completely in flux and
definitely doesn't work, but at least the comments might show you
where I'm going (this is my bullet point #3 above)

> Thanks,
> Tomeu

-------------- 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/20080506/e69de3fa/attachment.pgp 

More information about the Sugar-devel mailing list