[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
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/20080506/e69de3fa/attachment.pgp
More information about the Sugar-devel
mailing list