Re: [gtkmm] Bringing Bonobo to the masses :)

[Mathieu Lacage <mathieu eazel com>]

Miguel de Icaza <miguel helixcode com> writes:

> >  c) a special case of b) which is using component technology 
> >     to avoid writing language bindings all the time; 
> >     i.e. we have no library to go with components, just 
> >     use the components directly using the CORBA bindings for 
> >     a given language. This is how Microsoft supports 
> >     multiple languages.
> 
> Another issue (independent of your list) is that the Bonobo API is not
> just composed of the interfaces, but it also has bits of runtime that
> need to be mapped into whatever language (unless they are
> reimplemented and tracked into the other languages).
> 
> Bonobo wrapping will typically require IDL bindings for accessing new
> and exciting CORBA interfaces, but it will also require some API
> binding action for having some runtime reuse.  Sure, it can be fully
> reimplemented.  All of it, but it seems like a bit of a waste of time
> sometimes. 
> 
> In the Microsoft world, there is no full reimplementation of COM in
> other languages, they end up reusing the runtime bits of it and expose
> them to their various languages in various ways (like, GetObject in
> Visual Basic is nothing but a wrapper for a couple of C calls)

We are not talking of reimplementing COM but OLE/ActiveX and I am pretty
sure many applications do so. The main reason is probably that
COM in C++ is actually usable without too much hassle which is not the 
case of CORBA in C or C++.

"COM is even used for the internal interfaces of the code instead of 
using the C++ native mechanism" ---> microsoft employee quote.

<rant name="mathieu">
I personally think that if we managed to design a good GTK+ mapping 
for CORBA, we could actually do the same and I would love being able to 
reimplement the bonobo interfaces all the time The main reason is that
the IDL interfaces of bonobo are pretty straightforward but the layer on 
top of it (ie: the GTK wrappers) are bad in many ways:
        - they try to hide the underlying CORBA but do not succeed: CORBA
        objects lie around a little everywhere and are exposed to the 
        programmer.
        - they try to hide the internal workings of bonobo but this only 
        results in confusing design. (the fact that a BonoboControlFrame 
        exposes the API of the distant CORBA object to save programmers 
        the task of 1) getting the distant object reference 2) calling 
        the relevant method on this object.)
</rant>

If you forget about all this, life is good and my bike is going well, 
thank you :)



Mathieu
-- 
Mathieu Lacage <mathieu eazel com>