Re: Generic Embeddable plugins, Take 2

>
> Hi Marc,
>
> J.M. Maurer wrote:
>> After reading the whole Embedding thread, I think 'we' are confusing
>> some things.
>>
>> 1) The way martin plans to implement the Math plugin is *not* embedding
>> components. Martin's proposed API combined with a C api for the rest of
>> AbiWord presents a nice framework for future abiword plugins to use. It
>> would allow them to tightly integrate with AbiWord (such as the math
>> plugin) using a stable API (unlike we have now).
>>
>> 2) The embedding issue is a totally different problem. Embeddable
>> components would (generally speaking) not use anything from Abi such as
>> the Graphics classes, at all. Furthermore they will be running most
>> likely totally out of process. This means those embedded components will
>> NOT be tightly integrated with AbiWord. This is a feature, not a bug. If
>> you want really tight integrated plugins, use 1).
>>
>
> I actualy do not see real difference between the two. What Martin is
> proposing is embeded content, which is generated by a server that just
> happens to be AW plugin and makes use of AW internals. The other is
> embeded content generated by server that has no formal connection with
> AW. The former is clearly just a special case of the latter, and it
> seems to me that making a distinction between the two is
> contraproductive, leading to two sets of API that achieve excatly the
> same thing.
>
> I see no reason why the MathML plugin could not interface with AW in
> exactly the same as the as a generic embeded server would: we tell it
> this is your area of the document to draw into and it does so. Whether
> it uses our graphics class to do this, etc., is none of our business.
>
> More I think about this, the less I am happy about having to accomodate
> the layout classes to this specific problem, notably the creation of the
> fp_MathRun; it is not a generic solution to what is a generic problem.
> Even if the fp_MathRun is moved inside a plugin directory, it will still
> have to be added to the enum in fp_Run.
>
> There should be fp_EmbeddedContentRun class, providing generic inteface
> to the embedded server, and an architecture that would allow the server
> to connect to this interface. In the Math case, Martin can have
> fp_MathRun derrived from fp_EmbeddedContentRun, but AW would be
> oblivious to that, it would just be manipulating fp_EmbeddedContentRun;
> a code that would allow for ActiveX to be embedded would have its own
> derrived class, etc.
>
> The physical location and size of the fp_EmbeddedContentRun should be
> controlled by AW alone, not by the server; we give the server a space to
> work with. What the sever does within this space and how it does it is
> entirely up to it.
>

Yes. I agree with this. fp_mathRun.cpp currently lives inside
src/text/fmt/xp.

I would like to leave it seperate from fp_EmbedRun.cpp although it might
become a subclass of it.

I want to leave it distinct because Luca and I have been talking about
tighly integrating editting Math via GtkMathView and I want us to be free
to experiment with it for a bit.

Also I suspect that once we have fp_MathRun.cpp worked out we can create a
very good fp_EmbedRun.cpp usable by many other plugins.

Finally I should point out that I'm also think of creating a
fg_EmbedGraphics class so embedded content can be the background to
frames, cells, pages etc.

Cheers

Martin

> Tomas
>
Received on Mon Jan 17 13:38:27 2005