Re: [Glade-devel] A library API to Glade3 for other programs.

[paolo borelli <pborelli katamail com>]

On Mon, 2003-08-11 at 10:30, Archit Baweja wrote:
> There are 2 main ways of exposing the glade3's capabilities
> 
> 1) Bonobo || IDL interfaces. Lots of Bonobo/CORBA overhead involved. Gives us
> the glade3 develops more to do. But we have the advantage of starting "late"
> on working this without changing much of the code. With the other option, we
> might just have to start changing from the ground up.
> 
> 2) A simple C library API interface. Not much overhead. And saves the glade3
> developers lot of work. Projects wanting to embedd glade3 can encapsulate
> it by wrapping glade3 API calls in their own plugin/dock system.
> 
> During our discussion on #devel-tools on irc.gnome.org, we had sort of went in
> favour of option 2. But its the community's call.

For what is worth, I prefer option 2; not only because I'm lame and
don't know bonobo properly ;) but also for the following reasons:

- There has been rumors that in the future (2.6?) libglade (or something
equivalent) could be merged into gtk+: IMO it would make sense also have
a tool for creating .glade files that doesn't require any extra
dependencies.

- We've managed to keep glade3 codebase pretty small (using a lot of
gtk2 features that allow us to retrieve information from within the
GObject system) and I fear that switching to bonobo would bloat the
sources, making even harder to jump in and contribute to glade3.

- Glade3 works on Windows. I don't know if using bonobo would be a
problem on that platform.

So I would really prefer to stick with plain gtk.

This obviously does not mean that someone can't create a bonobo
component that wraps glade3 functionality, using this yet-to-be-done
library.

Beside I don't think that switching to a library requires that much
changes to the glade3 code: we're already pretty modular since most of
the code is a collection of independents widgets/objects (the palette,
the editor etc); the part that looks a little harder is
glade-command.[ch].

Opting for the library leaves us with a problem hard to solve...
since 'libglade' is already taken, how do we call it? ;)


ciao
	paolo