[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
glade & emacs
glade & emacs
Tue, 22 Apr 2003 18:39:37 +0100
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?
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> 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
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> We will eventually send an email when we'll have it working.
- glade & emacs,
Nick Roberts <=