Re: Specifying Office Component IDL?

[Michael Hoennig "(mi)" <mi sun com>]

Hi Mike,

> > > 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?

I don't the possibility of OpenOffice moving to CORBA instead of UNO in 
the near future. CORBA lacks of some features, we need. For further 
discussion about this topic please include our UNO team, probably 
dev uno openoffice org would be a better place. My idea of migration was 
always about the API itself, not the technology. This would mean, the API 
could be used from CORBA/Bonobo as well as from UNO, but the 
documentation would be one. Additionally, I was always speaking about 
MIGRATION of both APIs, not about converting OpenOffice to Bonobo/CORBA.

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

You may make this distinction, for me BOTH aspects are necessary for a 
specification of abstract objects.

> 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.

Right. Thus, I would more likely make a distinction of using services as 
specifications or as a kind of macro query for object activations, rather 
than you two flavors mentioned above.

> [the enum namespace problem]
> 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.

You're right. Thus, in transforming UNO IDL to CORBA IDL, we would simply 
prefix all enum values with the enum type:

module UNO_module_X
{
	enum EnumA
	{
		VALUE1, VALUE2;
	}
}

would become in CORBA IDL:

module CORBA_module_X
{
	enum EnumA
	{
		EnumA_VALUE1, EnumA_VALUE2;
	}
}

> > 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.

OK, I now see what your very interesting project is about. But still, I 
have no idea what it has to do with migrating OpenOffice to GNOMEs 
component technology. Probably the misunderstanding is, that we use the 
drawing API internally for all drawing acivities. Unfortunately we don't! 
Not are the "old" components still internally C++ only (no UNO) and only 
offer a wrapper for the API, additionally the drawing API 
com::sun::star::drawing is not an API for canvas output at all, like VCL 
(the C++ library, used in OpenOffice for the graphical user interface) 
offers.

OpenOffice cannot convert to GNOME technology, anyway. We will stay multi 
platform. Sharing APIs and interoperations is a great thing, but basing 
OpenOffice on GNOME would not be welcome by many people.

	Michaeö