unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* glade & emacs
@ 2003-04-22 17:39 Nick Roberts
  2003-04-23  2:59 ` Stephen J. Turnbull
  0 siblings, 1 reply; 2+ messages in thread
From: Nick Roberts @ 2003-04-22 17:39 UTC (permalink / raw)
  Cc: glade-devel


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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: glade & emacs
  2003-04-22 17:39 glade & emacs Nick Roberts
@ 2003-04-23  2:59 ` Stephen J. Turnbull
  0 siblings, 0 replies; 2+ messages in thread
From: Stephen J. Turnbull @ 2003-04-23  2:59 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> "Nick" == Nick Roberts <nick@nick.uklinux.net> writes:

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

It should work.  XEmacs implements libglade in the GTK configuration,
which is a pretty cool toy.  (Unfortunately nobody's gotten around to
wrapping it with interfaces to widget.el, so it doesn't get much past
"toy".)

Bill Perry <wmperry@gnu.org> is the guy who knows about it.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-04-23  2:59 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-22 17:39 glade & emacs Nick Roberts
2003-04-23  2:59 ` Stephen J. Turnbull

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).