(WARNING: Bear with me, I'm a complete zero to CORBA stuff)

On Tue, 20 Apr 1999 weis@stud.uni-frankfurt.de wrote:

> One just encapsulates as good as possible the whole CORBA interface
> with a KDE interface. That means: Map sequences to QValueList, String_var
> to QString and so on. I did that in KTrader. That seems to be more or less
> the same idea Stephan had. But I can tell you that it really starts to 
> suck if you have to change the idl interface and map it to the
> KDE interface. Everytime you change the IDL, you have to change the KDE 
> interface by hand and so on. Terrible on the long run.
> 
> In a kde library it is worth the efforts I think, but in application code ?
> I think I prefer waiting for the compiler a bit longer instead of hacking
> a KDE<-> CORBA layer all the time.

But what to do when we speak of a small app (like a wm) which *has*
to stay small and fast and would like to occasionally make use of CORBA.

Like, for example, relying on IDL for popping up a nicely behaved minicli
(complete with history,url completion and whatever) without having to
implement that minicli internally nor to know what app precisely the user
likes. Or, better example, communicate with a CORBA-enabled panel in order
to dynamically set dimensions, get system menu popped up etc, get icon
positions from a desktop manager, receive configuration commands from
theme designer or from control panel etc.

Of course, one can stay with the current X communication underground (and
this is precisely what I try to figure out) but would it be useful enough
to include corba in the wm, and at what extent (I mean, full support or
only the wrapping you say about and relying on the kded).

Thanks for bearing :-)

Cristian