Is anyone working on Gtk+-bindings for Common Lisp? That's something
I'd really like to have (for CMUCL to be more specific), and I've
often thought about trying to hack something together myself, but I
don't think I know the internals of Gtk+ (or Common Lisp for that
matter) well enough to be able to do a very good job.
I imagine that a lot of people would be interested in this and I'm
surprised no one has done it yet - considering that there are already
Gtk+-bindings for 11 different languages (including Guile Scheme, but
Common Lisp would be much nicer...); see
http://www.gtk.org/language-bindings.html
Fredrik Sandstrom | "I have never let my schooling
·······@infa.abo.fi | interfere with my education."
http://infa.abo.fi/~fredrik | - Mark Twain
·······@infa.abo.fi (Fredrik Sandstr�m) writes:
| Is anyone working on Gtk+-bindings for Common Lisp? That's something
Yes. I 100% accidentally found some fellow's WWW page which
even had an unannounced version downloadable. I don't have the
URL available right now (and even if I had, I'd prefer to wait
for the author to announce this himself as it seemed to be
work-in-progress), but if you are really interested in
alpha/beta state version and the author doesn't read this
newsgroup, I'll dig up that URL and post it here.
| I'd really like to have (for CMUCL to be more specific), and I've
It seemed to have support for ACL, CMUCL and CLISP. The design
seemed to be, um, weird so to say, but I don't want to comment
it here now especially because it isn't released yet and because
I don't know Gtk+ enough to say whether that was perhaps good
thing for some reason.
| often thought about trying to hack something together myself, but I
| don't think I know the internals of Gtk+ (or Common Lisp for that
| matter) well enough to be able to do a very good job.
Yeah, I too thought to hack Gtk+ bindings for CMUCL during
Christmas, but noticed that I don't understand Gtk+ enough and I
couldn't find good enough documentation :\
//Hannu
·······@infa.abo.fi (Fredrik Sandstr�m) writes:
>
> Is anyone working on Gtk+-bindings for Common Lisp? That's something
> I'd really like to have (for CMUCL to be more specific), and I've
> often thought about trying to hack something together myself, but I
> don't think I know the internals of Gtk+ (or Common Lisp for that
> matter) well enough to be able to do a very good job.
>
> I imagine that a lot of people would be interested in this and I'm
> surprised no one has done it yet - considering that there are already
> Gtk+-bindings for 11 different languages (including Guile Scheme, but
> Common Lisp would be much nicer...); see
> http://www.gtk.org/language-bindings.html
>
>
> Fredrik Sandstrom | "I have never let my schooling
> ·······@infa.abo.fi | interfere with my education."
> http://infa.abo.fi/~fredrik | - Mark Twain
I have gtk bindings for Common Lisp. There is no home page or
something similar yet. But feel free seek out for
cl-gtk-<date>.tar.gz in:
http://www.uni-karlsruhe.de/~unk6/export/
Like CLM, it uses a pipe to a gtk daemon written in C for portability
across different Common Lisp implementations. The interface code is
generated automatically from the gtk-guile .defs files.
Gilbert.
--
;;; You know you have hacked Lisp too much, when you m-c-x in a C buffer.
I personally have some doubts/misgivings about GTK. Especially when
you consider running it within a CL implementation.
The main problem that I see is that GTK seems designed to be a
"one-application" toolkit system. That is to say, you have no way to
get in the main event loop (at least not at this time).
Any comments on this?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> I personally have some doubts/misgivings about GTK. Especially when
> you consider running it within a CL implementation.
>
> The main problem that I see is that GTK seems designed to be a
> "one-application" toolkit system. That is to say, you have no way to
> get in the main event loop (at least not at this time).
>
> Any comments on this?
>
I have looked at this and it is a problem. GTK is more than a gui
toolkit, it includes lots of process management stuff and a primitive
reference counting garbage management scheme. The biggest problem
that I saw with interfacing with GTK is the problem of who gets to
call select. Both GTK and lisp (at least ACL) want to have that honor
which can cause lots of problems.
It would be really nice if they would have opened up that part of the
system like is done in xlib, where you can use the standard event
dispatch loop if you want but if you need to you can get at the raw
streams themselves and the the dispatching yourself. However, I don't
know how practical this is since the GTK code itself reenters the the
main dispatch loop recursively in several places. So once you have
written your own the old one just gets called again out side of your
control.
I have toyed with this in the past a couple of times trying to use
Allegro's cbind system to get GTK up and running. But the bugs in
cbind itself have prevented me from making any progress. I just figured
out a work around for one of the bigger bugs this past week so I may
try to get the GTK thing running again this weekend. Not running
nicely, but running.
-Eric
> Cheers
>
> --
> Marco Antoniotti ===========================================
> PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
> tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
> http://www.parades.rm.cnr.it
eric dahlman <·······@cs.colostate.edu> writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > I personally have some doubts/misgivings about GTK. Especially when
> > you consider running it within a CL implementation.
> >
> > The main problem that I see is that GTK seems designed to be a
> > "one-application" toolkit system. That is to say, you have no way to
> > get in the main event loop (at least not at this time).
> >
> > Any comments on this?
> >
>
> I have looked at this and it is a problem. GTK is more than a gui
> toolkit, it includes lots of process management stuff and a primitive
> reference counting garbage management scheme.
(with-sarcasm
"How amusing. How come I am not surprised? People should be a little
more creative. :}")
> The biggest problem
> that I saw with interfacing with GTK is the problem of who gets to
> call select. Both GTK and lisp (at least ACL) want to have that honor
> which can cause lots of problems.
>
...
So, it looks like the "best" way to use GTK is to set up a separate
process like CMUCL and CML do.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: ················@siemens.ch
Subject: Re: Gtk+-bindings for Common Lisp?
Date:
Message-ID: <ulnhu1t2c.fsf@siemens.ch>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> > The biggest problem
> > that I saw with interfacing with GTK is the problem of who gets to
> > call select. Both GTK and lisp (at least ACL) want to have that honor
> > which can cause lots of problems.
> >
> ...
> So, it looks like the "best" way to use GTK is to set up a separate
> process like CMUCL and CML do.
From what I remember in seeing the header files in GTK, they are others
way to make GTK bindings.
There exists a function (gtk_main_iteration_do) in GTK which enters
the main loop events for X11, but you can specify if you want to block
when no work needs to be done. Thus you could write a main loop
running on the Lisp side which does sometime some polling through this
function.
If your lisp handles OS level threads, you could also make a thread
running the GTK main event loop (GTK can be compiled thread safe) and
other threads run your Lisp code.
- Pierre.
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> So, it looks like the "best" way to use GTK is to set up a separate
> process like CMUCL and CML do.
No, the best way is to patch Gtk+ so that it behaves properly and
lobby for your changes to be included in the distro.
Marius Vollmer <···@zagadka.ping.de> writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > So, it looks like the "best" way to use GTK is to set up a separate
> > process like CMUCL and CML do.
>
> No, the best way is to patch Gtk+ so that it behaves properly and
> lobby for your changes to be included in the distro.
Of course. Not an easy feat though.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
eric dahlman <·······@cs.colostate.edu> writes:
>
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > I personally have some doubts/misgivings about GTK. Especially when
> > you consider running it within a CL implementation.
> >
> > The main problem that I see is that GTK seems designed to be a
> > "one-application" toolkit system. That is to say, you have no way to
> > get in the main event loop (at least not at this time).
> >
> > Any comments on this?
> >
> I have looked at this and it is a problem. GTK is more than a gui
> toolkit, it includes lots of process management stuff and a primitive
> reference counting garbage management scheme. The biggest problem
> that I saw with interfacing with GTK is the problem of who gets to
> call select. Both GTK and lisp (at least ACL) want to have that honor
> which can cause lots of problems.
Well, I faced these problems by putting the gtk stuff into another
process, which also solves the portability problems across the three
CL implementations I use regularly. (ACL, CLISP, CMUCL [alphabetical
order]). And portability is important for me.
The refernce counting stuff is a bit more complicated. What you want
is basically a cross process garbage collection. (Whether the gtk
library is in your address room or a separate process doesn't really
matter here). I not yet came up with a solution for it.
For a gtk binding to be really useful, it really should be possible to
define new [widget] classes. So I'll implement an ability to define
new gtk classes in Lisp. The gtk classes should be somehow
incorparated into CLOS. Maybe we need new meta classes to model the
gtk classes.
Graphics should then been done thru' CLX. No need to go thru' the gtk
daemon to access the gtk's gdk wrapper around libX11.
On the other hand GTK isn't exactly my dream toolkit. The idea to have
a gtk binding goes back to Sam Steingold. I then did a quick hack to
see, if it would be feasible. I personally probably won't use it that
often.
But gtk has some advantages: It has a lot of commitment and man-power
behind it, more that the Lisp crowd every could hope to get. (We are
just too few). Give it a year to mature, I am pretty convinced that
gtk will become something decent soon.
I use CLM a lot. But since most Linux machines do not have Motif
installed (since it costs money), I am currently at coding something
reasonable upon CLUE.
Gilbert.
--
;;; You know you have hacked Lisp too much, when you m-c-x in a C buffer.
>>>>> "Gilbert" == Gilbert Baumann <····@rz.uni-karlsruhe.de> writes:
Gilbert> I use CLM a lot. But since most Linux machines do not have Motif
Gilbert> installed (since it costs money), I am currently at coding something
But you do have Lesstif. The CLM that comes with CMUCL works fine
with Lesstif.
Gilbert> reasonable upon CLUE.
I was never able to get a clue with CLUE, perhaps because I don't grok
X. Garnet is about the same size and does much, much more, if you
don't require CLOS for your windowing stuff. Perhaps Garnet is too
slow with CLISP?
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
>
> >>>>> "Gilbert" == Gilbert Baumann <····@rz.uni-karlsruhe.de> writes:
>
> Gilbert> I use CLM a lot. But since most Linux machines do not have Motif
> Gilbert> installed (since it costs money), I am currently at coding something
>
> But you do have Lesstif. The CLM that comes with CMUCL works fine
> with Lesstif.
It perhaps depends on your application. First I do not use the CMUCL's
CLM, but the GMD implementation, which is portable across CL
implementations. Second thing, my application does not work or behaves
strange with Lesstif. I simply found it unrealiable, so Motif isn't
any longer in the game.
> Gilbert> reasonable upon CLUE.
>
> I was never able to get a clue with CLUE, perhaps because I don't grok
> X.
CLUE is tighly coupled with X11. It is basically an implementation of
Xt in Lisp. Since I am quite familiar with Xt and X11 in general, I
just needed a couple of hours to get up to speed to implement the
needed widget classes using CLUE. Reading the manual from cover to
cover helps a bit.
> Garnet is about the same size and does much, much more, if you
> don't require CLOS for your windowing stuff.
That is of course a bit exaggerated. My copy of garnet is 140k lines.
CLUE is 10k. Then CLUE is a bare bones toolkit not featuring anything
useful. I have another 3k lines of code, which adds the most basic
widgets in Motif-look. I expect it will grow to 6k. So with 16k lines
of code I have all I need. I am currently porting the GUI from CLM, so
to have something, which has the same roots, helps a bit.
I do not touch CLIO. I found it very bug ridden and kind of unusable.
> Perhaps Garnet is too slow with CLISP?
It used to be on my 486/33, I now have a machine, which is 15 times
faster than that -- so speed isn't the problem. And CLUE isn't really
that faster. And since their gcontext caching bites the CLX
implementation in C, I did for CLISP, for all practial purposes CLUE
is slower under CLISP than Garnet. (CLUE digs too deep into the
implementation details of CLX).
I am not advocating any particular toolkit here; I am taking a
pragmatic approach and use what is available and want could be sold to
the masses. This implies Motif look-and-feel, despite I am not a fan
of that either.
Gilbert.
--
;;; You know you have hacked Lisp too much, when you m-c-x in a C buffer.
>>>>> "Gilbert" == Gilbert Baumann <····@rz114s1.rz.uni-karlsruhe.de> writes:
Gilbert> It perhaps depends on your application. First I do not use the CMUCL's
Gilbert> CLM, but the GMD implementation, which is portable across CL
Gilbert> implementations. Second thing, my application does not work or behaves
Gilbert> strange with Lesstif. I simply found it unrealiable, so Motif isn't
Gilbert> any longer in the game.
Ok. CLM in CMUCL didn't work with Lesstif until fairly recently when
a few real bugs in the Motif code were fixed. I don't use CLM
either. I just know that CMUCL CLM with Lesstif at least brings up a
debugger window that works like real Motif does.
>> Garnet is about the same size and does much, much more, if you
>> don't require CLOS for your windowing stuff.
Gilbert> That is of course a bit exaggerated. My copy of garnet is 140k lines.
Gilbert> CLUE is 10k. Then CLUE is a bare bones toolkit not featuring anything
I meant the resulting core sizes. But perhaps I'm thinking that
CLUE+CLIO is the same size as Garnet? I don't remember.
Gilbert> I am not advocating any particular toolkit here; I am taking a
Gilbert> pragmatic approach and use what is available and want could be sold to
Likewise. When I do GUI stuff (on rare occasions) on free Lisps, I
use Garnet because I understand the manual, but Garnet is also
somewhat buggy. I don't do CLUE because I don't understand X11 or Xt.
Ray
CLUE is (was) the right approach, a bottom-up CLOS-layered toolkit for
X-windows,
though it has just enough abstraction to not be low-level like Xt.
Too bad the majority of lisp vendors didn't further it and bet on
the top-down CLIM monster instead.
> CLUE is tighly coupled with X11. It is basically an implementation of
> Xt in Lisp. Since I am quite familiar with Xt and X11 in general, I
>..
> > Garnet is about the same size and does much, much more, if you
> > don't require CLOS for your windowing stuff.
>
> That is of course a bit exaggerated. My copy of garnet is 140k lines.
> CLUE is 10k. Then CLUE is a bare bones toolkit not featuring anything
> useful. I have another 3k lines of code, which adds the most basic
> widgets in Motif-look. I expect it will grow to 6k. So with 16k lines
> of code I have all I need. I am currently porting the GUI from CLM, so
> to have something, which has the same roots, helps a bit.
>
Kelly Murray <···@IntelliMarket.Com> writes:
> CLUE is (was) the right approach, a bottom-up CLOS-layered toolkit for
> X-windows,
> though it has just enough abstraction to not be low-level like Xt.
> Too bad the majority of lisp vendors didn't further it and bet on
> the top-down CLIM monster instead.
>
Very good question indeed.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
Gilbert Baumann <····@rz.uni-karlsruhe.de> writes:
> The refernce counting stuff is a bit more complicated. What you want
> is basically a cross process garbage collection. (Whether the gtk
> library is in your address room or a separate process doesn't really
> matter here). I not yet came up with a solution for it.
Perhaps you could look at how authors of guile-gtk and PyGtk (Python
Gtk binding) solved this problem?
> For a gtk binding to be really useful, it really should be possible
> to define new [widget] classes.
Why? In Python, this is not possible, and I have yet to find a
problem with that. PyGtk implements classes that correspond to Gtk+
widgets, so you can create a Gtk window like this:
window = GtkWindow ()
But you can also do this:
from gtk import *
class MyWindow (GtkWindow):
"""Window with a message."""
def __init__ (self, message):
GtkWindow.__init__ (self)
self.connect ("destroy", mainquit)
self.set_title (message)
label = GtkLabel (message)
self.add (label)
window = MyWindow ("hellow world")
window.show_all ()
mainloop ()
This is a trivial example, but you can inherit this on all you like,
and create anything you want. Of course, the caveat is that your
stuff will not be visible and identifiable as Gtk widgets *from C*,
but it if you want that, you should probably write the widgets in C in
the first place.
If you implement similar functionality using CLOS, you should get
the same advantages.
From: Christopher R. Barry
Subject: Re: Gtk+-bindings for Common Lisp?
Date:
Message-ID: <87soc3o58o.fsf@2xtreme.net>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> I personally have some doubts/misgivings about GTK. Especially when
> you consider running it within a CL implementation.
>
> The main problem that I see is that GTK seems designed to be a
> "one-application" toolkit system. That is to say, you have no way to
> get in the main event loop (at least not at this time).
>
> Any comments on this?
I was going to comment just on the fact of "what's the point?". GTK is
about as OO as you can get in C, but it's not like a class library or
anything. Every GTK app is like a box in a box in a box.... It worked
really well in The Gimp, but most GTK apps are (IMHO) really ugly
without the themes support (can anyone name an app to prove me
wrong?), which as far as I know is still in the unstable branch.
Garnet lets you use the Motif look-and-feel or roll your own and is so
much more usable and nicer (IMHO).
Qt and the GNUStep stuff are nicer toolkits (IMHO) to but they each
force C++ and ObjC on you respectively.
Christopher
Christopher R. Barry <······@2xtreme.net> wrote:
> Qt and the GNUStep stuff are nicer toolkits (IMHO) to but they each
> force C++ and ObjC on you respectively.
Didn't ACL on NS2.1 have bindings to interact with the ObjC environment?
Were they maintained in any releases after it was unbundled? Also, were
there any ACL releases for OS4.x?
<N/>
From: R. Matthew Emerson
Subject: Re: *STEP bindings for CL (was Gtk+-bindings for Common Lisp?)
Date:
Message-ID: <7ak2jl$lrg$1@news-1.news.gte.net>
····@po.cwru.edu (Natarajan Krishnaswami) writes:
>
> Christopher R. Barry <······@2xtreme.net> wrote:
> > Qt and the GNUStep stuff are nicer toolkits (IMHO) to but they each
> > force C++ and ObjC on you respectively.
>
> Didn't ACL on NS2.1 have bindings to interact with the ObjC environment?
> Were they maintained in any releases after it was unbundled? Also, were
> there any ACL releases for OS4.x?
there was an interface to objc. but you could only create one
application object. if you wanted to make another one, you had
to restart your lisp. also, when you exited the application,
your lisp exited too! this was surely a result of the appkit
taking control of event processing and not letting go.
[finds old ACL for NeXTstep docs...]
it went like this:
(make-application "foo")
(send NXApp :loadNibFile=owner= "foo.nib" NXApp)
(send NXApp :run)
the bundled lisp was 3.1.20 (i still have it), and i seem to recall
that the whole objc thing got dropped when ACL4 finally came out for
the NeXT.
-matt
······@2xtreme.net (Christopher R. Barry) writes:
>
> I was going to comment just on the fact of "what's the point?". GTK is
> about as OO as you can get in C, but it's not like a class library or
> anything. Every GTK app is like a box in a box in a box.... It worked
> really well in The Gimp, but most GTK apps are (IMHO) really ugly
> without the themes support (can anyone name an app to prove me
> wrong?), which as far as I know is still in the unstable branch.
I am no big GTK fan either. But then you have to use something, which
is available. I am really tired of the whole GUI toolkit discussions
and flame wars. Every week another toolkit is "in". And as in real
life there is more concern about the look than about the
implementation details.
And then the GTK implementors seem to acknowledge, that C isn't the
perfect language. You only have to take a look at their glib or their
gdk wrapper around libX11. Somebody of the gtk crowd must have been
exposed to Lisp and CLX.
> Qt and the GNUStep stuff are nicer toolkits (IMHO) to but they each
> force C++ and ObjC on you respectively.
Is Qt free yet?
Gilbert.
--
;;; You know you have hacked Lisp too much, when you m-c-x in a C buffer.
From: Christopher R. Barry
Subject: Re: Gtk+-bindings for Common Lisp?
Date:
Message-ID: <877ltdopfc.fsf@2xtreme.net>
Gilbert Baumann <····@rz.uni-karlsruhe.de> writes:
> Is Qt free yet?
RMS thinks the new QT Public License is kosher.
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> I was going to comment just on the fact of "what's the point?". GTK
> is about as OO as you can get in C, but it's not like a class
> library or anything. Every GTK app is like a box in a box in a
> box.... It worked really well in The Gimp, but most GTK apps are
> (IMHO) really ugly without the themes support (can anyone name an
> app to prove me wrong?),
Sure: GQmpeg, GQview, most of Gnome stuff, electric eyes, Gtk-based
font and color selectors, gtkfind, etc.
From: Christopher R. Barry
Subject: Re: Gtk+-bindings for Common Lisp?
Date:
Message-ID: <87d835opo4.fsf@2xtreme.net>
Hrvoje Niksic <·······@srce.hr> writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > I was going to comment just on the fact of "what's the point?". GTK
> > is about as OO as you can get in C, but it's not like a class
> > library or anything. Every GTK app is like a box in a box in a
> > box.... It worked really well in The Gimp, but most GTK apps are
> > (IMHO) really ugly without the themes support (can anyone name an
> > app to prove me wrong?),
>
> Sure: GQmpeg, GQview, most of Gnome stuff, electric eyes, Gtk-based
> font and color selectors, gtkfind, etc.
Well, I'll agree to disagree with you on this. I like the color
selectors, and I like The Gimp, but most of that Gnome stuff....
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> > Sure: GQmpeg, GQview, most of Gnome stuff, electric eyes,
> > Gtk-based font and color selectors, gtkfind, etc.
>
> Well, I'll agree to disagree with you on this.
Heh, it takes two to agree, even about disagreement. :-)
You didn't comment on applications other than Gnome things.