[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: A new framework for embedding ... without CORBA
From:       Jo Dillon <emily () thelonious ! new ! ox ! ac ! uk>
Date:       1999-09-29 12:57:58
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]