Re: Scaffold, plugins and language independence



On Mon, 2004-02-09 at 17:46, Mikoyan wrote:
> On Mon, 2004-02-09 at 15:51 -0500, John (J5) Palmieri wrote:
> > On Mon, 2004-02-09 at 14:51, Bart Van Rompaey wrote:
> > > On Mon, 2004-02-09 at 13:13, Christian Leutloff wrote:
> 
> [ .. snip ... ]
> 
> > > So I thought communication between plugins in those different languages
> > > and the "core" could be done using Corba/Bonobo, since all those
> > > languages have libraries for this. The core can be further developed in
> > > glib c, and can keep using gdl, gnomebuild, ... . This way, you can
> > > provide the largest possible freedom to the plugin writer too.
> > 
> > We dropped Corba/Bonobo for the simplicity of developing with GModules. 
> > The old plugin system relied heavily on Corba/Bonobo which turned a lot
> > of plugin writers off.  Interfaces may later be wrapped in Corba/Bonobo
> > bindings but for now a nice C interface with Python bindings seems like
> > the path of least resistance.  Even the Glade-3 developers have frowned
> > on using Bonobo and instead wanted a modularized C API.  
> 
> I do not pretend to have *the knowlegde*, so I may be wrong with I'm
> saying here. But GModule is only usable for C and C++ (using export C)
> plugins. I think GModule and GInterfaces are indeed easier for the
> plugin writer if the plugin writer is a C/C++ developer.

Python is tied closely to C.  It is described as a C glue language. 
Basically what would have to happen is that a GModule would need to be
created that embeds python and exposes an API for obtaining references
to other Scaffold elements (i.e. the ValueContainer API).  Since Glib
and GTK are mostly wrapped all that is needed is to wrap the few
Scaffold interfaces.  The wrappers take care of marshaling/demarshaling
the Glib types.  If other plugins need to interact with the python
plugins it will do so through established interfaces (not sure if
GObject introspection will work).  I still need to investigate pyGTK's
support GObject Interfaces but since the drag and drop interfaces are
supported I wouldn't see why it would be a problem with our plugin
system.

> I still do not see how a python plugin would be loaded by scaffold... It
> may be possible, but I don't know one. Please enlighten me. The only way
> I see, is a C plugin invoking a python program. Suboptimal, to say the
> least.

Actualy this is how Gnome-build works with perl by creating a pipe to
parse the Makefile.am's.  It is suboptimal.

> Corba/Bonobo is *not* hard. Their is just a sheer lack of documentation.
> The biggest problem of GNOME. I could start a preach here, but I won't.
> That in combination, with a sheer lack of expertise among the gnome
> community, makes bonobo hard. Let's change that :-)

I agree but it has been decided to use GModule.  Like I said in another
e-mail, Bonobo can just become another wrapper if someone really wants
to use it. 

> But it is a fact that Corba/Bonobo from python is quite easy. Actually,
> i think it's even beautiful. (think: automatic stub and skell generation
> at runtime when loading the idl, sigh, do I sound biased?). I don't see
> why it shouldn't be used.

Easy to use.  Corba C marshaling code I have heard is a pain in the
butt.

> I've used the gedit component in one of my thesis related prototypes,
> using bonobo in python. If the thing was probably documented, I had
> written that code in no time. (Take that almost litterly). 
> As Bart once said: "if something is probalby documented, it does need to
> scare anyone". :-)

Glimmer is the bonobo wrapper for GtkSourceView that Scaffold uses.  I
am not sure if that will change.

> Even in C things like BonoboListener and BonoboEventsource, a possible
> system for communciation between components, cannot be called hard. But
> as I said, GModule would fit beter here, I guess.

I always said Bonobo myself but I really don't see any great loss.
  If it turns out we want it it is easy enough to add.  At least now we
start with the simpler solution and get things moving.

> Only my 2 ¤-cents of course :-)

Glad to read it.

> Mikoyan

--
J5




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]