-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nigel Tao schrieb: > Just a thought I had when playing around with the 2.19 series. It's > had a good scrubbing in the refactoring effort, but e.g. extensions > written for the 2.18 series no longer work. > > It might be possible to write an adapter class to convert a 2.18 style > Handler to a 2.20 style Module (e.g. wrap or dynamically mix-in or > some other Python magic) an old-style Handler to add a get_actions() > method to a 2.18 Match object, for example. For that to be even > feasible, we would have to be able to tell the old and new style > apart. > The only possibility could be that old style handlers return DummyMatches and the old-style Match gets wrapped by a Action. It's just a quick thought. However, I think it won't be easy to get old-style handlers working properly in 2.20.
> Fortunately, we can distinguish between 2.18 (and 2.16 and 2.14) style > Handlers and 2.20 style Modules because the former live in > ~/.gnome2/deskbar-applet/handlers and the latter in > ~/.gnome2/deskbar-applet/modules. Which is all well and good. But > suppose that we do another refactoring in 2.26 that breaks API > compatibility again. We might not find a suitable name that isn't > "Handler" or "Module". > > Thus, it might be better to rename ~/.gnome2/deskbar-applet/modules to > ~/.gnome2/deskbar-applet/modules-2.20-compatible > > Similarly, we might want to rename history_new.pickle to > history-2.20-compatible.pickle, or in general, stamp a version on > anything persistent, in anticipation of future backwards > incompatibility. > You're absolutely right. If nobody has an objection I'll put it in the next release on Monday. > Also, we might require Module writers to implement an > is_compatible_with(deskbar_version) method or maybe a > get_module_for_deskbar_version(deskbar_version_string) method. For > example, [1] presents a Tracker Handler/Module that attempts to be > both 2.14 and 2.20 compatible. I'm not sure if it's best if the core > deskbar code does this sort of conditional loading, or whether the > extension writers do this. It would be nice if, supposing we broke > the Module API in 2.32, that my old 2.20 Module still worked with > Deskbar 2.32 since Deskbar 2.32 first asked for a 2.32-compatible > version and, failing that, adapted a 2.20-compatible version. > That's the smaller problem. If you can write an adapter for old-style classes this step won't take much. - -- Greetings, Sebastian Pölsterl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1vDM1ygZeJ3lLIcRAqDWAJoDCYZgSnz3Z0pgIQwl2LcZX6yd+gCgqJM2 2yqxZ07OBNfxOgc57udGmM4= =tP+v -----END PGP SIGNATURE----- _______________________________________________ deskbar-applet-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/deskbar-applet-list
