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
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
