glade & emacs

[Nick Roberts]

Below is a transcript of a dialog that I have had with Joaquin Cuenca Abela
on glade-devel (http://lists.ximian.com). Following my experience of trying
to get Emacs to interact with GDB, I thought it would be a good idea to ask
what features Glade has/would have for communication through Emacs. I guess
I have two questions for the emacs-devel mailing list:

1) Are my basic aims compatible with those of Emacs?

2) Joaquin asks if there are any problems for Emacs with the approach that
the Glade project are proposing. I can only make the general remarks that I
have given. Can somebody else provide a deeper insight?

Nick


Me> ...More generally, I'm interested in improving Emacs as an IDE. Now that
Me> Emacs can be built with GTK, I would like to try to integrate Glade into
Me> its operation. My initial ideas are quite basic: I would write a set of
Me> lisp commands for Emacs that could start Glade, load new projects and
Me> access the source code for editing and compiling. It is easy to create a
Me> subprocess in Emacs to start Glade but communication between processes is
Me> a bit more difficult. Unfortunately, I know very little about GTK but I
Me> can see that features like drag and drop require communication (signals?)
Me> between different GTK applications. Ideally I would like to access this
Me> communication with the Emacs lisp commands that I would write. GDB
Me> developers have recently developed an interface called GDB/MI where MI
Me> stands for machine interface. It was written to allow communication
Me> with GUI front-ends.

Me> Does Glade have something similar?


JCA> No, glade doesn't has a MI.

JCA> Once we have glade installable as a library, you should be able to link
JCA> to it dynamically and just use its public API (yet to be defined,
JCA> unfortunatelly).

JCA> I'm not very excited about supporting a MI on glade, specially if we get
JCA> the glade-as-a-library approach to work.

JCA> Do you see any problem with this approach?  That's what we want to use
JCA> to integrate with anjuta, and I hope that it will work out to be enough
JCA> for emacs.


Me> I was thinking of a looser coupling. A command line interface, possibly an
Me> MI, with a few simple commands like:

Me> 1) load filename - so that emacs/parent appplication could load a new 
project
Me> into glade without creating a new instance.

Me> 2) projectdir - to tell emacs/parent appplication the current project
Me> directory for tasks like editing/copiling the relevant files.

Me> which could be invoked as an option e.g `glade --cli'

Me> This would also a flexible framework for adding further commands when and as
Me> needed. However, it might also be a lot of work (although there is plenty of
Me> prior art) and perhaps it doesn't fit in with the general plans for glade. 

Me> How can I stay informed about the glade-as-a-library approach?


JCA> I know that it's more on the emacs "tradition" to work with others
JCA> applications just forking and communication over a pipe.  But really,
JCA> what's the added benefit over just using glade as a library?

JCA> If you load glade dynamically you will not have a compile-time
JCA> dependency, so I guess that the only concern is that you may have to do
JCA> a internal copy of our exposed headers if you want to keep an absolutely
JCA> glade independent build.

JCA> My main concern with having a MI on glade is that it will be more work
JCA> (at the end we may want to implement everything that's in the public
JCA> API) on my side and on your side.

JCA> I'm not absolutely closed to having a MI, as I'm quite pragmatic.  If
JCA> that's the only way to get glade working on emacs, then I'll reexamine
JCA> this point.  But I would like to hear some real problems (as dlopen is
JCA> not portable enough for emacs, for instance ;-)

JCA> > How can I stay informed about the glade-as-a-library approach?

JCA> Here.

JCA> We will eventually send an email when we'll have it working.