I know that there are some packages available. I just wonder what are
the most stable? And which one has bindings to LispWorks and SBCL?
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Friedrich wrote:
> I know that there are some packages available. I just wonder what are
> the most stable? And which one has bindings to LispWorks and SBCL?
What do you mean by "stable" in this context? The stability of an
application built on the package? The stability of the interface over time?
Apart from that, there is a list in [1]. Of those, I have looked at
cells-gtk, clg, and lambda-gtk. To me, the major distinction is their
respective level of abstraction. For you, compatibility with lispworks
might be an even stronger filter.
lambda-gtk [2] is almost a 1:1 mapping of GTK, but runs only on OpenMCL,
SBCL, and CMUCL.
clg [3] is more lispish and provides a clos interface to GTK, but runs
only on CMUCL, SBCL and CLISP
cells-gtk [4] -- my persnal favorite -- is cells inside (which is the
best way to do a GUI in my opinion). It is the only one I know of which
supports Lispworks on both Linux and Windows (along with
Allegro(Windows), CLISP(Linux, PC), SBCL(Linux), and CMUCL(Linux)).
Just for compatibility reasons, cells-gtk might be your choice. OTOH it
is quite different from raw GTK, so you will have to get used to it. I
recommend to get the latest version from CVS [5] which has a number of
improvements over the (two year old) tar release.
Currently there is ongoing work to port it to cells 3 (the current
version uses cells 2), to add an interactive cairo drawing area, and an
opengl widget. The latest version sits in the cells cvs [6].
HTH,
Peter
[1] http://www.cliki.net/GTK%20binding
[2] http://common-lisp.net/project/lambda-gtk/
[3] http://www.cliki.net/clg
[4] http://common-lisp.net/project/cells-gtk/
[5] http://common-lisp.net/cgi-bin/viewcvs.cgi/root/?cvsroot=cells-gtk
[6] http://common-lisp.net/cgi-bin/viewcvs.cgi/cells-gtk3/?root=cells
>
> Regards
> Friedrich
>
Peter Hildebrandt <·················@gmail.com> writes:
> Friedrich wrote:
>> I know that there are some packages available. I just wonder what are
>> the most stable? And which one has bindings to LispWorks and SBCL?
>
> What do you mean by "stable" in this context? The stability of an
> application built on the package? The stability of the interface over
> time?
the later, stability of the interface over time.
>
> lambda-gtk [2] is almost a 1:1 mapping of GTK, but runs only on
> OpenMCL, SBCL, and CMUCL.
>
> clg [3] is more lispish and provides a clos interface to GTK, but runs
> only on CMUCL, SBCL and CLISP
that's no good news.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Peter Hildebrandt wrote:
> lambda-gtk [2] is almost a 1:1 mapping of GTK, but runs only on OpenMCL,
> SBCL, and CMUCL.
>
> clg [3] is more lispish and provides a clos interface to GTK, but runs
> only on CMUCL, SBCL and CLISP
>
> cells-gtk [4] -- my persnal favorite -- is cells inside (which is the
> best way to do a GUI in my opinion). It is the only one I know of which
> supports Lispworks on both Linux and Windows (along with
> Allegro(Windows), CLISP(Linux, PC), SBCL(Linux), and CMUCL(Linux)).
>
Please dont misunerstand my question, it should not be an offense, it is
only a question. I was wondering why it is (or seems) so hard to create
a portable GTK-Binding for CL. GTK is available on almost all Platforms
(as long as you use C/C++), what is the problem with creating portable
GTK-Bindings for Common Lisp? Isnt it enough to just use CFFI? I am
neither a GTK-Programmer, nor an expierienced CL-Programmer, but at
least as far as I know, GTK has nothing "difficult" except that it uses
Callbacks (which the CFFI supports in almost all CL-Versions), but since
much more expierienced people seemed to fail (I have not found a really
portable one yet, but as far as I read, cells-gtk is ported to the CFFI
now), there must be some problem. I am just interested, what that
problem is. I dont really need a portable GTK-Binding, but anyway this
is an interesting question.
C S S wrote:
> Peter Hildebrandt wrote:
>> lambda-gtk [2] is almost a 1:1 mapping of GTK, but runs only on
>> OpenMCL, SBCL, and CMUCL.
>>
>> clg [3] is more lispish and provides a clos interface to GTK, but runs
>> only on CMUCL, SBCL and CLISP
>>
>> cells-gtk [4] -- my persnal favorite -- is cells inside (which is the
>> best way to do a GUI in my opinion). It is the only one I know of
>> which supports Lispworks on both Linux and Windows (along with
>> Allegro(Windows), CLISP(Linux, PC), SBCL(Linux), and CMUCL(Linux)).
>>
>
> Please dont misunerstand my question, it should not be an offense, it is
> only a question. I was wondering why it is (or seems) so hard to create
> a portable GTK-Binding for CL. GTK is available on almost all Platforms
> (as long as you use C/C++), what is the problem with creating portable
> GTK-Bindings for Common Lisp? Isnt it enough to just use CFFI? I am
> neither a GTK-Programmer, nor an expierienced CL-Programmer, but at
> least as far as I know, GTK has nothing "difficult" except that it uses
> Callbacks (which the CFFI supports in almost all CL-Versions), but since
> much more expierienced people seemed to fail (I have not found a really
> portable one yet, but as far as I read, cells-gtk is ported to the CFFI
> now), there must be some problem. I am just interested, what that
> problem is. I dont really need a portable GTK-Binding, but anyway this
> is an interesting question.
My guess: size, mostly. Conversions can be mostly mechanized (a la
verrazano or swig) but then you feel like you're coding C in lisp -- a
most unpleasant experience. Adding a sane wrapper takes time,
directly proportional to the size of the library being bound...
Besides, Qt is vastly superior to GTK, so why bother. ;)
- Daniel
D Herring <········@at.tentpost.dot.com> writes:
> Besides, Qt is vastly superior to GTK, so why bother. ;)
Huh? There are good and mature bindings to Qt for Common Lisp
available? Which? Everything http://www.cliki.net/Qt mentions are dead
links/projects.
--
Stefan.
D Herring wrote:
>> Please dont misunerstand my question, it should not be an offense, it
>> is only a question. I was wondering why it is (or seems) so hard to
>> create a portable GTK-Binding for CL. GTK is available on almost all
>> Platforms (as long as you use C/C++), what is the problem with
>> creating portable GTK-Bindings for Common Lisp? Isnt it enough to just
>> use CFFI? I am neither a GTK-Programmer, nor an expierienced
>> CL-Programmer, but at least as far as I know, GTK has nothing
>> "difficult" except that it uses Callbacks (which the CFFI supports in
>> almost all CL-Versions), but since much more expierienced people
>> seemed to fail (I have not found a really portable one yet, but as far
>> as I read, cells-gtk is ported to the CFFI now), there must be some
>> problem. I am just interested, what that problem is. I dont really
>> need a portable GTK-Binding, but anyway this is an interesting question.
>
>
> My guess: size, mostly. Conversions can be mostly mechanized (a la
> verrazano or swig) but then you feel like you're coding C in lisp -- a
> most unpleasant experience. Adding a sane wrapper takes time, directly
> proportional to the size of the library being bound...
>
> Besides, Qt is vastly superior to GTK, so why bother. ;)
I dont like Qt, but as soon as the GUI-Library would work on as many
Combinations of Systems as possible, and as soon as it was
well-documented, I would use it (as soon as I needed it ^^). Is the
situation better for Qt?
To me it sounds better to have a portable Alternative that feels like C
in lisp (where you can write your wrappers around, to make it more
lisp-like if you need it), than to have some funny-lispy-thingy that
works only for one or two Lisp-Compilers on one or two Operating
Systems. But I guess one can argue about that.
I think, the best Widget-API is AWT (Java), where you can use
"interfaces" to implement "listeners" for events (i.e. you dont use
callbacks directly). It is abstract, i.e. not bound to a special
graphical environment (ok, it has functions which are, but the "basics"
are not), and can also be implemented for Use in Web-Applications or in
Terminals. I think, one could use the CLOS for this, too. The CLOS has
no Interfaces (or abstract methods), but you could use classes with
default methods, which can be overwritten, and which do nothing per
default. But I dont know if this is "lisp-style", but I like it.
C S S wrote:
> Please dont misunerstand my question, it should not be an offense, it is
> only a question. I was wondering why it is (or seems) so hard to create
> a portable GTK-Binding for CL. GTK is available on almost all Platforms
> (as long as you use C/C++), what is the problem with creating portable
> GTK-Bindings for Common Lisp? Isnt it enough to just use CFFI?
Yep, I'd say so -- and this is what cells-gtk does, and why it runs on a
number of implementations.
As I said before, the question is what you want out of your GTK
bindings. You can have everything from a 1:1 mapping to a complete
lispy GUI library which just happens to use GTK as a backend. IMHO
there is no right answer to this question, which is why we have a
multitude of libraries.
clg and lambda-gtk (I think!) are automatically generated and thus
complete. Why they use the sbcl/cmucl FFI and not cffi? I don't know,
ask the developers. Lambda-gtk is the straightforward 1:1 mapping and
feels like writing C. OTOH it is quite easy to translate C GTK code
into lambda-gtk Lisp code. clg uses some clever tricks to make writing
in lisp more pleasing, but it still is gtk in the end of the day.
cells-gtk heavily uses cells to make GUI programming a lot more lispy.
The value of cells-gtk is more the cells part; the bindings are only a
minor part of it.
To the OP: If you want "just gtk on cffi", you can pull the gtk-ffi
package from cells-gtk and use that directly. It is not as complete as
clg or lambda-gtk, but should be sufficient in most cases.
Stepping back a little, I think the solution would be to
- merge the binding generator from clg with the cffi-based binding
macros from cells-gtk/gtk-ffi to create complete bindings
- add cells-gtk to run on top of these bindings
However, I don't have the time do this at this point. Plus, the
manually created bindings in cells-gtk's gtk-ffi are good enough for me,
and I'd rather focus on adding cool lispy functionality (like the opengl
and cairo stuff) than to add more low level gtk calls I don't need anyway.
> (I have not found a really
> portable one yet, but as far as I read, cells-gtk is ported to the CFFI
> now)
Again, the gtk-ffi part in cells-gtk is as portable as it gets with cffi.
Peter
C S S wrote:
> Peter Hildebrandt wrote:
>> lambda-gtk [2] is almost a 1:1 mapping of GTK, but runs only on
>> OpenMCL, SBCL, and CMUCL.
>>
>> clg [3] is more lispish and provides a clos interface to GTK, but runs
>> only on CMUCL, SBCL and CLISP
>>
>> cells-gtk [4] -- my persnal favorite -- is cells inside (which is the
>> best way to do a GUI in my opinion). It is the only one I know of
>> which supports Lispworks on both Linux and Windows (along with
>> Allegro(Windows), CLISP(Linux, PC), SBCL(Linux), and CMUCL(Linux)).
>>
>
> Please dont misunerstand my question, it should not be an offense, it is
> only a question. I was wondering why it is (or seems) so hard to create
> a portable GTK-Binding for CL. GTK is available on almost all Platforms
> (as long as you use C/C++), what is the problem with creating portable
> GTK-Bindings for Common Lisp? Isnt it enough to just use CFFI? I am
> neither a GTK-Programmer, nor an expierienced CL-Programmer, but at
> least as far as I know, GTK has nothing "difficult" except that it uses
> Callbacks (which the CFFI supports in almost all CL-Versions), but since
> much more expierienced people seemed to fail (I have not found a really
> portable one yet, but as far as I read, cells-gtk is ported to the CFFI
> now), there must be some problem. I am just interested, what that
> problem is. I dont really need a portable GTK-Binding, but anyway this
> is an interesting question.
It is mind-numbingly boring to create bindings manually.
..but it does work. There is nothing "missing in CL" that stops one from
doing this.
Doing it automatically by parsing C header files doesn't work 100%.
..it is quite unrewarding or unsatisfying, in a sense IMHO. It doesn't
"feel right".
Doing it by communicating with GTK+ via GObject doesn't work 100% either.
..but this is a very nice approach IMHO. It "feels right".
I have tried the GObject approach. But of course there are limitations
in GObject and more importantly, I think, in GTK+ that prevent this from
working as good as it could.
It seems there are significant parts of GTK+ that are not "connected"
with the GObject stuff still. I think work is done in improving this
now. I might try again later.
By the way .. FFIing with a C++ library (the problem is C++) like QT is
not nice, if QT does not provide something like GObject that is. But
then you are stuck with something that has licensing issues. For some
with "a lot of money" this might not be a problem but for others it is.
But what we really need is pure Lisp from the bottom up. Or at least
from a more lower level than GTK+/QT. Maybe by building something on CLX
and cl-opengl. Using GTK+/QT will always seem like a hack or something
temporary IMHO.
--
Lars Rune N�stdal
http://nostdal.org/
Lars Rune N�stdal wrote:
> But what we really need is pure Lisp from the bottom up. Or at least
> from a more lower level than GTK+/QT. Maybe by building something on CLX
> and cl-opengl. Using GTK+/QT will always seem like a hack or something
> temporary IMHO.
Why not some abstract API-Specification that can be implemented in
several ways? Why does it always have to be connected with CLX or
cl-opengl, why drawing it directly? I dont think that this is the right way.
This is what the Java-API does right: It is abstract enough to be made
accessible in many ways (i.e. charva, jnlp, etc.), but still powerful,
and - if you have a good backend - comparably easy to port, I think.
On 2008-04-20, C S S <···@swissjabber.ch> wrote:
> Why not some abstract API-Specification that can be implemented in
> several ways? Why does it always have to be connected with CLX or
> cl-opengl, why drawing it directly? I dont think that this is the right way.
> This is what the Java-API does right: It is abstract enough to be made
> accessible in many ways (i.e. charva, jnlp, etc.), but still powerful,
> and - if you have a good backend - comparably easy to port, I think.
You are describing LispWorks CAPI.
C S S wrote:
> Lars Rune N�stdal wrote:
>> But what we really need is pure Lisp from the bottom up. Or at least
>> from a more lower level than GTK+/QT. Maybe by building something on
>> CLX and cl-opengl. Using GTK+/QT will always seem like a hack or
>> something temporary IMHO.
> Why not some abstract API-Specification that can be implemented in
> several ways? Why does it always have to be connected with CLX or
> cl-opengl, why drawing it directly? I dont think that this is the right
> way.
> This is what the Java-API does right: It is abstract enough to be made
> accessible in many ways (i.e. charva, jnlp, etc.), but still powerful,
> and - if you have a good backend - comparably easy to port, I think.
Well, of course. But it would eventually have to be rendered using some
back-end "connected to" a C based OS/library because that is what we
have atm.
..and instead of connecting the default lowest level back-end to
something like GTK+ or QT it would be better to connect with something
lower level and build something Lispy on that I think, replacing GTK+ or
QT.
It needs to be so low level that all the stuff one build is Lisp and
Lisp only; full introspection using CLOS/MOP etc.
--
Lars Rune N�stdal
http://nostdal.org/
Lars Rune Nøstdal wrote:
> ...and instead of connecting the default lowest level back-end to
> something like GTK+ or QT it would be better to connect with something
> lower level and build something Lispy on that I think, replacing GTK+ or
> QT.
>
> It needs to be so low level that all the stuff one build is Lisp and
> Lisp only; full introspection using CLOS/MOP etc.
Maybe I'm mistaken, but isn't this what McCLIM does?
Personally, I prefer using a mid-level library (even if it is written in
C), simply because the application will integrate nicely with the rest
of the OS (skins, themes, settings, look'n'feel). Thanks to Great Stuff
such as Ken Tilton's Cells we can abstract away so much of the C
interface, that using cells-gtk or celtk really does not feel like
you're working on top of a hack.
Peter
Peter Hildebrandt <·················@gmail.com> writes:
> Lars Rune N�stdal wrote:
>> ...and instead of connecting the default lowest level back-end to
>> something like GTK+ or QT it would be better to connect with
>> something lower level and build something Lispy on that I think,
>> replacing GTK+ or QT.
>> It needs to be so low level that all the stuff one build is Lisp and
>> Lisp only; full introspection using CLOS/MOP etc.
>
> Maybe I'm mistaken, but isn't this what McCLIM does?
AFAIKT doesn't CLIM conform with any other "programming model". And
the portability is very wacky AFAIKT. I tried my luck with MCclim and
LispWorks CLIM once and it was simply terrible.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
On Apr 20, 1:13 pm, C S S <····@swissjabber.ch> wrote:
> Lars Rune Nøstdal wrote:
> > But what we really need is pure Lisp from the bottom up. Or at least
> > from a more lower level than GTK+/QT. Maybe by building something on CLX
> > and cl-opengl. Using GTK+/QT will always seem like a hack or something
> > temporary IMHO.
>
> Why not some abstract API-Specification that can be implemented in
> several ways?
I think y'all are describing McCLIM, at least in concept.
> Why does it always have to be connected with CLX or
> cl-opengl, why drawing it directly? I dont think that this is the right way.
In McCLIM, those would simply be backends (CLX is used as a
backend).
> This is what the Java-API does right: It is abstract enough to be made
> accessible in many ways (i.e. charva, jnlp, etc.), but still powerful,
> and - if you have a good backend - comparably easy to port, I think.
To do it right, you need good abstractions and well implemented back
ends. The CLIM spec, from what I have heard, has its fair share of
warts and doesn't "map well" to how many modern GUI developers think;
also, the backends need a LOT of TLC and work. A good backend is not
a trivial matter - you are essentially mapping the abstractions of
McCLIM to specifics on the particular platform, and doing that Right
can be a challenge. Aside from large feature lists needed you may
also get FFI issues if you have to handle a system graphics API in
another language. Different OS versions will have changes you must
cope with. Etc. Very much worth doing, but not an undertaking for
the faint of heart.
C S S wrote:
> Why not some abstract API-Specification that can be implemented in
> several ways? Why does it always have to be connected with CLX or
> cl-opengl, why drawing it directly? I dont think that this is the right
> way.
> This is what the Java-API does right: It is abstract enough to be made
> accessible in many ways (i.e. charva, jnlp, etc.), but still powerful,
> and - if you have a good backend - comparably easy to port, I think.
Funny, I had a very similar idea when I saw some of Andy Chamber's
OpenAIR code on cells-devel: It looks like all the cells based GUI
libraries (Celtk, cells-gtk, and now OpenAIR) provide rather similar
interfaces.
Therefore I think it won't be too much work to abstract out a common set
and provide a macrology which can expand into celtk (for native
appearance on windows/mac), cells-gtk (for native appearence on linux),
or even OpenAIR (for web apps).
All you'd need to do is change a flag somewhere, and you application
could compile into a windows, linux, mac or even web application. How
about that?
Peter
Peter Hildebrandt wrote:
> C S S wrote:
>
>> Why not some abstract API-Specification that can be implemented in
>> several ways? Why does it always have to be connected with CLX or
>> cl-opengl, why drawing it directly? I dont think that this is the
>> right way.
>> This is what the Java-API does right: It is abstract enough to be made
>> accessible in many ways (i.e. charva, jnlp, etc.), but still powerful,
>> and - if you have a good backend - comparably easy to port, I think.
>
>
> Funny, I had a very similar idea when I saw some of Andy Chamber's
> OpenAIR code on cells-devel: It looks like all the cells based GUI
> libraries (Celtk, cells-gtk, and now OpenAIR) provide rather similar
> interfaces.
>
> Therefore I think it won't be too much work to abstract out a common set
> and provide a macrology which can expand into celtk (for native
> appearance on windows/mac), cells-gtk (for native appearence on linux),
> or even OpenAIR (for web apps).
>
> All you'd need to do is change a flag somewhere, and you application
> could compile into a windows, linux, mac or even web application. How
> about that?
Funny, I had a very similar idea <g> when I liewise noticed the
repeating pattern of driving GUI X from CLOS proxies via Cells -- I have
to suspect we would end up with one of those least common denominator
compromise deals. Then the project becomes fun iff the LCD rocks /and/
one has an application in which one cannot choose upfront between Tk and
Gtk. But what if WebKit suffices cross-platform such that OpenAIR truly
flies? Do we still need Tk or Gtk?
Probably too many options at this point to make any sense out of it.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"I've never read the rulebook. My job is to catch the ball."
-- Catcher Josh Bard after making a great catch on a foul ball
and then sliding into the dugout, which by the rules allowed the
runners to advance one base costing his pitcher a possible shutout
because there was a runner on third base.
"My sig is longer than most of my articles."
-- Kenny Tilton
Ken Tilton wrote:
>
>
> Peter Hildebrandt wrote:
>> C S S wrote:
>>
>>> Why not some abstract API-Specification that can be implemented in
>>> several ways? Why does it always have to be connected with CLX or
>>> cl-opengl, why drawing it directly? I dont think that this is the
>>> right way.
>>> This is what the Java-API does right: It is abstract enough to be
>>> made accessible in many ways (i.e. charva, jnlp, etc.), but still
>>> powerful, and - if you have a good backend - comparably easy to port,
>>> I think.
>>
>>
>> Funny, I had a very similar idea when I saw some of Andy Chamber's
>> OpenAIR code on cells-devel: It looks like all the cells based GUI
>> libraries (Celtk, cells-gtk, and now OpenAIR) provide rather similar
>> interfaces.
>>
>> Therefore I think it won't be too much work to abstract out a common
>> set and provide a macrology which can expand into celtk (for native
>> appearance on windows/mac), cells-gtk (for native appearence on
>> linux), or even OpenAIR (for web apps).
>>
>> All you'd need to do is change a flag somewhere, and you application
>> could compile into a windows, linux, mac or even web application. How
>> about that?
>
> Funny, I had a very similar idea <g> when I liewise noticed the
> repeating pattern of driving GUI X from CLOS proxies via Cells -- I have
> to suspect we would end up with one of those least common denominator
> compromise deals. Then the project becomes fun iff the LCD rocks /and/
> one has an application in which one cannot choose upfront between Tk and
> Gtk. But what if WebKit suffices cross-platform such that OpenAIR truly
> flies? Do we still need Tk or Gtk?
I'd say, yes. I don't believe in simulating a web environment locally,
it just feels wrong. I remember someone saying all-X-all-the-time is
usually a Bad Idea, and I believe this approach of using WebApp
technology for every use case is an example of that.
More precisely:
- I think that a common GUI DSL could be the Right Thing for a lot of
use cases, iff the back ends are expressive enough to allow for a
reasonable functionality
- I think that OpenAIR has the potential to implement a large enough set
of GUI functions to keep the LCD with Gtk/Tk at a useful level
- However, I believe we have to be very careful where we draw the line
between generic GUI DSL and back end. In particular, I think making
OpenAIR part of the generic thing goes too far -- I would not want
Ajax/JavaScript in an application which could use good ol' plain Tk/Gtk
(and run ten times as fast). I think OpenAIR would be a good back end
given the constraints of the web browser environment. I don't think the
whole Ajax business in a general purpose solution.
> Probably too many options at this point to make any sense out of it.
Yep, which is why I'd commit myself not more than necessary. In
particular I would not want to commit myself to Ajax/JS for desktop
apps. I can see that we'll have a convergence of those channels in the
future, but I don't think it will be built on the technology we have
right now.
To give an example: Have you looked at the XUL stuff for mozilla?
There you have a declarative language for GUI development. XUL apps run
as fast and as nice as native apps, they offer a full blown set of
widgets, and they scale well (in fact, firefox is written in it). The
catch: it works only on mozilla browsers. However, I believe something
like that is to come as a standard sooner or later. And then I'd love
to just switch backend and not have prematurely committed to the current
web 2.0 stuff. I'd rather use Gtk/Tk in the meantime :-)
Peter
Lars Rune N�stdal wrote:
> By the way .. FFIing with a C++ library (the problem is C++) like QT is
> not nice, if QT does not provide something like GObject that is. But
> then you are stuck with something that has licensing issues. For some
> with "a lot of money" this might not be a problem but for others it is.
All Qt objects use a rather complete reflection framework; IIRC, this
was used for much of Paul Reutz's Lisp bindings.
In 1998, the KDE Free Qt Foundation received permission to release Qt
under a BSD license if Qt Free Edition were ever discontinued. In
2000, Qt/Unix 2.2 was GPLd, and a MS Windows port gained traction in
2002. In 2005, Qt 4 was released under the GPL for all platforms.
GTK is LGPL.
I don't see much difference for Lisp licensing between the two.
- Daniel