On Tue, May 06, 2008 at 04:39:30PM +0200, Tomeu Vizoso wrote:
> On 5/4/08, Martin Dengler <[EMAIL PROTECTED]> 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
pgp6oA04ymjJy.pgp
Description: PGP signature
_______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
