Re: [Libreoffice] How to call from one component to another (sw->starmath)

On Monday 15 of August 2011, Miklos Vajna wrote:
> On Mon, Aug 15, 2011 at 05:16:17PM +0200, Lubos Lunak <l.lunak@suse.cz> 
wrote:
> >  I'm implementing .docx OOXML support for writing math formulas. As this
> > is something that could be used not only by Writer but also by other
> > components, I want to implement the writing of the formula in Starmath.
> > And even if I didn't want, Sm* classes (which implement and store the
> > formulas) are in starmath/ , and sw-starmath do not link against each
> > other.
> >
> >  So, the question is, how do I call from sw to starmath without linking
> > them together? I checked how the binary .doc filter does it, and it goes
> > via ~10 calls deep [1] that call some UNO interfaces and store the result
> > in some private stream or whatever. But I find that needlessly
> > complicated, as I already have a pointer to SmModel and SmDocShell (I can
> > get it the same way the .doc code does) and just need to call their
> > method, passing the XML serializer object as an argument, that's it.
> >
> >  The best I've come up with creating let's say
> > offapi/com/sun/star/starmath/WriteMath.idl with the function, make
> > SmModel inherit from that and cast&call using it in sw. But I have not
> > much idea about UNO, so I don't know what the stuff under offapi/
> > actually really is about. Is this a good solution or does somebody know
> > something better?
>
> That looks fine, that's how the rest of writerfilter can live without
> the Sw* classes. Did you check if the existing uno api is enough for
> you? See the output of 'git ls-files starmath|grep uno'. If yes, then
> you don't have to mess with offapi. :)

 You missed two important parts :). "I'm implementing", so this is new code 
and thus no existing UNO API, and more importantly, "needlessly complicated", 
which means I'll probably still rather go with those 10 nested calls than 
introduce the hard-to-develop-and-debug UNO writerfilter nightmare to new 
code.

 Trying with offapi has turned out to be equally complicated, all the involved 
classes need to be based on UNO interfaces and then comes trouble with 
refcounting (no wonder some places in the codebase are such messed up hacks, 
when trying to do things "properly" makes one realize it's just not worth the 
effort).

  For now I've just linked sw to starmath locally so that I can actually 
develop something. If no better solution turns up, I think I'll eventually go 
for the simple and working way of introducing a plain C++ interface class in 
some library that both sw and starmath use and go with that.

-- 
 Lubos Lunak
 l.lunak@suse.cz