RE: [XaraXtreme-dev] Tools folder - what is it good for?

[Alex Bligh <alex@xxxxxxxxxxx>]

--On 24 March 2006 18:09 +0000 Charles Moir <CharlesM@xxxxxxxx> wrote:

> Er, but remember it is a current goal that we will one day have a really
> modular Xara LX that has real plug-in tools, like Artworks.
>
> We cannot abandon that goal, (we're already rather un-competitive in
> this area already). Just looks the value it had for Artworks (new tools
> being developed 10 years after we stopped work on it). Indeed we proved
> 25 years ago that extendable apps are good for everyone.
>
> Inkscape and many other products are all moving to being more modular,
> more plug-in orientated, so we should not be moving the other way.

Sure, but the current way of doing it is broken broken broken broken broken.
Tools make heavy internal use of kernel objects, and for any useful tool
interface there has to be not only a stable API (i.e. source) but a
stable ABI (i.e. binary object layer). The former is hard enough with
a changing project, the latter is IMPOSSIBLE at a C++ level. To give
an obvious example, add a virtual function to the Node class, and any
tool which directly accesses any derivative of Node will have all its
vtable moved about, so will need recompilation. That *doesn't work*.

So either we have to come up with a separate (C-like) binary interface,
which is stable, but which will severely limit what can be done in tools,
or we can leverage the open-source status of the product, and suggest
people distribute tools in source form, and compile against a sequence of
headers we provide (which is by far the most flexible solution). C++ is
just not designed for plug-ins (IMHO), and where it IS used (see wxWidgets
efforts for stable-release ABI consistency) it needs to be REALLY
carefully thought through. And certainly the current system (I
believe) could never be usefully made to work in an environment where the
underlying classes change (possibly controversial, but heh, throw bricks
at me :-) ).

HOWEVER, whatever we decide to do, the current arbitrary distinction
of where tools go in terms of what directory they are in is unhelpful,
and not relevant to the above discussion. For instance, the ops to
move tool blobs about mostly live in the kernel already, tools call
randomly between eachother, the kernel calls directly into the tools,
the tools call directly into the kernel. And some of the tools have
nasty Oil dependent bits in. So we might as well dump it as misleading.

Alex