-----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+gCg
qJM2
2yqxZ07OBNfxOgc57udGmM4=
=tP+v
-----END PGP SIGNATURE-----
_______________________________________________
deskbar-applet-list mailing list
deskbar-applet-list gnome.org
http://mail.gnome.org/mailman/listinfo/deskbar-applet-
list
|
