From kde-core-devel  Wed Sep 29 12:57:58 1999
From: Jo Dillon <emily () thelonious ! new ! ox ! ac ! uk>
Date: Wed, 29 Sep 1999 12:57:58 +0000
To: kde-core-devel
Subject: Re: A new framework for embedding ... without CORBA
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93860972725876

David Faure (David.Faure@CRAMER.CO.UK) spake thusly:
> Let's take an example :
> a menu in kspread is either a QPopupMenu or an OPMenu.
> We have to choose here, we can't do both.

  Hmm - I was talking specifically about Bonobo support here. It seems
to me that what we'd need to do is optionally provide a CORBA interface
that takes calls from a Bonobo object saying 'manage my menu', which would
be translated to a QPopupMenu. I.e. not actually Openparts as such, just
a compatibility layer for bonobo.

> An embedded part wants to add its item into it when embedding itself.
> The first one can only be accessed through the Qt API => same process only
> the second one, though being physically a QPopupMenu for us, implements an
> IDL
> interface, so it can be accessed from a remote process as well.
>                                                         ^^^^^^
> Oh yes your point is very good : we could keep the Openparts interface, but
> do 'local' embedding for koffice, using the canessa-like way. 
> In the example above, the menu would still be an OPMenu, but would
> be used as a QPopupMenu (it inherits from it) for koffice purposes.
> 
> What do you (all) think ?

  Right, this is what I had in mind. Hmm. If our main use of CORBA
is to be compatible with gnome components in KDE 3.0 maybe we should
drop mico for orbit? ;)

-- 

	Jo