Re: Specifying Office Component IDL?

[Mike Kestner <mkestner ameritech net>]

"Michael Hoennig (mi)" wrote:

> > Is the API going to migrate to an Org::OpenOffice:: namespace?
> 
> Probably yes, probably no. If there is a high pressure from the
> community, we could do that. BUT it is "expensive". Not only is it a lot
> of work, it breaks existing external code too.

To convert it to CORBA and take advantage of bonobo, I suspect this
external code will have to break anyway, right?
 
> It would be great to have our service concept in CORBA, but I do not see
> much chance for this. Most CORBA users have a completely different
> approach than we (desktop folks) do. But I don't see problems in using
> the service concept as a "structured documentation" additionally to pure
> CORBA IDLs, we could simply change the filename extension.

There seem to be two primary flavors of services.  Aggregators and
Descriptors.  Descriptors are nothing but Property lists to be added to
a PropertyBag. 

For the most part, the aggregators can just be "structured
documentation" like you suggest.  However, it may be worthwhile to use
the top level service for an object as a queryable parameter by OAF. 
All of the Shapes I've looked at so far expose PropertyBag, Embeddable,
Shape, and Persist interfaces. Thus the most granular oaf query would
return every possible Shape.  It would be nice to have a way to get a
RectShape without explicitely providing it's OAFIID.   

> No name clashes anymore, if simply all enums are put into a separate sub
> module. Our IDLs are similar to CORBA but not CORBA itself, anyway. Thus
> this additional module could be added to the IDLs in the transition
> process.

If I understand you correctly, this produces:

module com::sun::star::drawing::FillStyle {
	enum FillStyle {
		NONE,
		...

To use this from a C binding, I need to do something like:

	com_sun_star_drawing_FillStyle_FillStyle style;

	switch(style) {

	case com_sun_star_drawing_fillstyle_NONE:
		yadayada;

Ick.

> Surely, I welcome such cooperations. But I do not understand what exactly
> you mean with using the OpenOffice Drawing API as a testbed. Please
> specify. Thanks!

What I am suggesting is that I am trying to create an implementation of
the OO drawing API using GNOME component technology.  Specifically
CORBA, Bonobo, and the GNOME canvas.  I was under the impression that
the plan was to migrate OO to GNOME technology. The drawing API seems to
be a relatively small (119 IDL files) yet significant module of the
API.  Perhaps we could use it as a learning opportunity in how the
overall conversion can be accomplished.

I'm not sure about Abiword, but both Gnumeric and Achtung are built off
the GnomeCanvas.  I read once where the Abihackers were considering
providing a RichText Canvas item for use in GO apps.  The canvas seems
to me the obvious core technology to build a GNOME office suite.

Regards,
Mike