From: Andrei Stebkov
Subject: Lisp and GUI on Linux/Windows
Date:
Message-ID: <417af13c@news.nnrp.ca>
Hi,
I wrote a few small apps (no gui) using CMUCL under Linux but I am still
quite confused on which way is best to start writing GUI apps both under
Windows and Linux. I spend about half of my programming time on Windows and
half on Linux and would like to know if there is a toolkit (library) that
would allow me to use the same approach on both OSs.
I heard something about CLIM, GTK and TK bindings for CL but couldn't find
any comprehensible manuals/tutorials on these libs.
I guess all I need is some pointers (maybe links) on how can I start
building GUI apps on windows (using CLISP) and Linux (CLISP or CMUCL).
Thanks,
Andrei
Andrei Stebkov <········@tht.net> writes:
> Hi,
>
> I wrote a few small apps (no gui) using CMUCL under Linux but I am still
> quite confused on which way is best to start writing GUI apps both under
> Windows and Linux. I spend about half of my programming time on Windows and
> half on Linux and would like to know if there is a toolkit (library) that
> would allow me to use the same approach on both OSs.
> I heard something about CLIM, GTK and TK bindings for CL but couldn't find
> any comprehensible manuals/tutorials on these libs.
> I guess all I need is some pointers (maybe links) on how can I start
> building GUI apps on windows (using CLISP) and Linux (CLISP or CMUCL).
A good bet would be LTK.
<minion> ltk: LTK is a Common Lisp Graphics Toolkit Library for Tk, by means
of talking to a Tcl interpreter. http://www.cliki.net/ltk
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: Andrei Stebkov
Subject: Re: Lisp and GUI on Linux/Windows
Date:
Message-ID: <417b1046@news.nnrp.ca>
Pascal Bourguignon wrote:
> A good bet would be LTK.
>
> <minion> ltk: LTK is a Common Lisp Graphics Toolkit Library for Tk, by
> means
> of talking to a Tcl interpreter. http://www.cliki.net/ltk
>
Thanks, Pascal!
As all roads lead to Rome everything seems to point at TK :)
I tried it and it works (though I tried just a few examples from the
tutorial on Peter Herth's site).
The strongest point of it is that the library is very easy to port and
install. As it communicates with wish via the stream, I wonder if it's
possible to display video on a canvas?
Does anyone have some sample code where they use more advanced windows
layouts?
Andrei
Andrei Stebkov wrote:
> As all roads lead to Rome everything seems to point at TK :)
> I tried it and it works (though I tried just a few examples from the
> tutorial on Peter Herth's site).
> The strongest point of it is that the library is very easy to port and
> install. As it communicates with wish via the stream, I wonder if it's
> possible to display video on a canvas?
> Does anyone have some sample code where they use more advanced windows
> layouts?
Well, because it communicates via a stream, displaying video by putting
the pixels one by one on the screen from lisp certainly won't work.
However, you can wrap Tk extensions widgets easily, so if you have an
extension widget, that can display video by itself, it should work
nicely. For example, for Mac OS X there is a quicktime widget for Tk,
so I can play any quicktime content in a Ltk application there.
Concering more advanced windows layout, do you have something especial
in mind ?
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: Andrei Stebkov
Subject: Re: Lisp and GUI on Linux/Windows
Date:
Message-ID: <417ba8d2@news.nnrp.ca>
Peter Herth wrote:
> However, you can wrap Tk extensions widgets easily, so if you have an
> extension widget, that can display video by itself, it should work
> nicely. For example, for Mac OS X there is a quicktime widget for Tk,
> so I can play any quicktime content in a Ltk application there.
> Concering more advanced windows layout, do you have something especial
> in mind ?
>
> Peter
>
Yes, Peter. As I have no experience with TK I'd like to see more examples on
how to implement MDI interface (multiple windows inside a parent frame).
How to play a video in a window, how to wrap Tk extensions.
Do you think it's a good idea that I learn some Tcl/Tk stuff first and then
use ltk?
Thank you,
Andrei
Andrei Stebkov wrote:
> Yes, Peter. As I have no experience with TK I'd like to see more examples
> on how to implement MDI interface (multiple windows inside a parent
> frame). How to play a video in a window, how to wrap Tk extensions.
> Do you think it's a good idea that I learn some Tcl/Tk stuff first and
> then use ltk?
Well, for the things covered by Ltk (and that is the functionatality of Tk
to rather 100%) you do not need Tcl/Tk knowledge. However if you want to
use some of the plenty extension libraries you might need some. In the
documentation to Ltk I have included an example how to wrap these libraries
on your own. But perhaps first just get comfortable with Ltk :)
Towards the other points: Tk (and thus Ltk) does not offer MDI interface, as
it is really a windows only thing. There is a Tk extension for Quicktime
which can play video for example. I have a wrapper for it for Mac OS, if
you want it, drop me an email.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: Christopher C. Stacy
Subject: Re: Lisp and GUI on Linux/Windows
Date:
Message-ID: <uk6tgr9mh.fsf@news.dtpq.com>
For cross-platform GUI systems, there are two obvious choices.
I use CAPI, which is part of Lispworks.
(I suspect that Allegro also has something comparable to CAPI.)
There is also CLIM, which runs on Lispworks, Allegro, and MCL.
Christopher C. Stacy wrote:
> For cross-platform GUI systems, there are two obvious choices.
> I use CAPI, which is part of Lispworks.
> (I suspect that Allegro also has something comparable to CAPI.)
It doesn't.
From: Christopher C. Stacy
Subject: Re: Lisp and GUI on Linux/Windows
Date:
Message-ID: <uhdoihfoe.fsf@news.dtpq.com>
mikel <·····@evins.net> writes:
> Christopher C. Stacy wrote:
>
> > For cross-platform GUI systems, there are two obvious choices.
> > I use CAPI, which is part of Lispworks.
> > (I suspect that Allegro also has something comparable to CAPI.)
>
> It doesn't.
What _does_ it have for GUI interfaces?
In article <·············@news.dtpq.com>,
······@news.dtpq.com (Christopher C. Stacy) wrote:
> mikel <·····@evins.net> writes:
>
> > Christopher C. Stacy wrote:
> >
> > > For cross-platform GUI systems, there are two obvious choices.
> > > I use CAPI, which is part of Lispworks.
> > > (I suspect that Allegro also has something comparable to CAPI.)
> >
> > It doesn't.
>
> What _does_ it have for GUI interfaces?
On win32 they have something similar to CAPI, called Common Graphics.
Not that I have made a feature-by-feature comparison.
I would ask the vendor if they plan to port that to OS X or Linux. I
seem to recall a Franz person saying an OS X port was happening, but
that was quite a while ago.
They are probably waiting for me to finish Cello so they can use that,
:)
Kenny
Kenneth Tilton wrote:
> In article <·············@news.dtpq.com>,
> ······@news.dtpq.com (Christopher C. Stacy) wrote:
>
>
>>mikel <·····@evins.net> writes:
>>
>>
>>>Christopher C. Stacy wrote:
>>>
>>>
>>>>For cross-platform GUI systems, there are two obvious choices.
>>>>I use CAPI, which is part of Lispworks.
>>>>(I suspect that Allegro also has something comparable to CAPI.)
>>>
>>>It doesn't.
>>
>>What _does_ it have for GUI interfaces?
CLIM.
> On win32 they have something similar to CAPI, called Common Graphics.
> Not that I have made a feature-by-feature comparison.
>
> I would ask the vendor if they plan to port that to OS X or Linux. I
> seem to recall a Franz person saying an OS X port was happening, but
> that was quite a while ago.
There are some obstacles to the OS X port that are being worked on.
Notably, Mach 'thinks different' about dynamic library linking, and some
code needs to be written to deal with that, and when that problem is
solved, there are many foreign interfaces to create.
On Linux, an interface to Gtk is to some degree working.
> They are probably waiting for me to finish Cello so they can use that,
I don't think that's true, though it's no reflection on Cello that it
isn't. Certainly, I'm still interested in Cello on all platforms. The
mass of required libraries is a little daunting, though.
mikel <·····@evins.net> writes:
> >>>>For cross-platform GUI systems, there are two obvious choices.
> >>>>I use CAPI, which is part of Lispworks.
> >>>>(I suspect that Allegro also has something comparable to CAPI.)
> >>>
> >>>It doesn't.
> >>
> >>What _does_ it have for GUI interfaces?
>
> CLIM.
I believe you have to pay extra for CLIM(btw they have a GTK interface for wich
utilities exists for transforming glade .xml files to ACL GTK instructions.
> On Linux, an interface to Gtk is to some degree working.
See above. I got clg (from Espen Johannesen) working on CMUCL, and it seems
to work well (not for gtk2.0 though). It is capable of reading glade files
as well, so you get an interface builder for free too.
I have not tested this, but GTK gui's in Lisp should be (quite) easily ported
to Windows. Most unixes work with GTK too.
> I'm still interested in Cello on all platforms. The
> mass of required libraries is a little daunting, though.
The last point here is *very* true.
--
Oyvin
Oyvin Halfdan Thuv wrote:
> mikel <·····@evins.net> writes:
>
>>I'm still interested in Cello on all platforms. The
>>mass of required libraries is a little daunting, though.
>
>
> The last point here is *very* true.
>
Cello is hard...let's go shopping!
:)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> Oyvin Halfdan Thuv wrote:
>
>> mikel <·····@evins.net> writes:
>>
>>> I'm still interested in Cello on all platforms. The
>>> mass of required libraries is a little daunting, though.
>>
>>
>>
>> The last point here is *very* true.
>>
>
> Cello is hard...let's go shopping!
I don't blame you for using all those libraries--that's smart--but that
long list smells of time sink. Without thinking much about it, I just
continue to circulate amongst the too many projects I've got going,
probably in some sort of subconscious hope that if I stall long enough,
Cello will become more complete and easier to install.
Being as how I haven't tried installing it lately, it may be that my
phobia is entirely irrational.
Go ahead: tell me it's irrational, and Cello is the right substrate for
Hansa2, so that I don't have to rewrite all the OSX-specific UI code for
Windows and then once again for Linux.
In article <···················@newssvr21.news.prodigy.com>,
mikel <·····@evins.net> wrote:
> Kenny Tilton wrote:
> >
> >
> > Oyvin Halfdan Thuv wrote:
> >
> >> mikel <·····@evins.net> writes:
> >>
> >>> I'm still interested in Cello on all platforms. The
> >>> mass of required libraries is a little daunting, though.
> >>
> >>
> >>
> >> The last point here is *very* true.
> >>
> >
> > Cello is hard...let's go shopping!
>
> I don't blame you for using all those libraries--that's smart--but that
> long list smells of time sink. Without thinking much about it, I just
> continue to circulate amongst the too many projects I've got going,
> probably in some sort of subconscious hope that if I stall long enough,
> Cello will become more complete and easier to install.
That might happen. It is a two-way street. I have to work on my own
cross-platform software now, so I cannot afford to kill hours on
promoting Cello qua public project unless there is a public giving back.
The good news is that Frank Goenninger, author of the Linux port, is now
working with me (doing most of the work so far) on the OS X port, and he
is a one-man open source project team, so I am prepared to don my fairy
wings again.
And I will need binary installers for customers, so you can look for
those eventually.
>
> Being as how I haven't tried installing it lately, it may be that my
> phobia is entirely irrational.
Oh, you tried already? Which platform? Did you hit the cells-devel list
for support? I honestly do not remember. Note that cello-devel and the
whole cl-net cello project has been abandoned now that cello is back
under the cells project there.
Anyway, yes, your phobia is irrational. All the libraries are mature,
solid libraries which build reliably if they do not actually have binary
installs. The Cello configuration process is being refined as we speak
to be as painless as possible, and refinements will continue if anyone
reports trouble -- I am just guessing now at what would be clean.
Granted Frank is a force of nature, but he ported Cello to Linux in just
a few days and with about three emails from me. He apparently had no
problems building all the libraries on OS X. We are having more fun on
OS X because I want to switch to Apple's Glut instead of Freeglut (which
we would have to port and then still would require X11) and Apple's Glut
has a couple of modest differences to accommodate -- nothing terrifying
yet, touch wood.
>
> Go ahead: tell me it's irrational,...
OK. It's (as easy as) pi.
> and Cello is the right substrate for
> Hansa2, so that I don't have to rewrite all the OSX-specific UI code for
> Windows and then once again for Linux.
From what I see on your web site, you still have a ways to go on the
functionality before worrying about ports. And you are not going
horribly fast. If so, the timing might work out well for you: Cello
should be universal by the time you need it. Then you can decide if you
like it, or if you should look at another solution such as LTk or Celtic
(+ Cells LTk).
kt
Kenneth Tilton wrote:
[Reassurances snipped]
> In article <···················@newssvr21.news.prodigy.com>,
> mikel <·····@evins.net> wrote:
Okay, I should probably get some approximately-now version of Cello and
try it out. Remind me: where should I get it.
>>and Cello is the right substrate for
>>Hansa2, so that I don't have to rewrite all the OSX-specific UI code for
>> Windows and then once again for Linux.
>
>
> From what I see on your web site, you still have a ways to go on the
> functionality before worrying about ports. And you are not going
> horribly fast. If so, the timing might work out well for you: Cello
> should be universal by the time you need it. Then you can decide if you
> like it, or if you should look at another solution such as LTk or Celtic
> (+ Cells LTk).
Right, I don't move terribly fast. I have a short attention span and
advance one project at a time in time-slicing fashion, modulated by how
many people are bugging me to release new versions of one project or
another. By this last criterion, Bosco usually wins. Hansa has been at
the bottom of the priority list long enough that I'm getting annoyed and
want to make a release some time soon, so I've done work on it recently
that is not reflected on its project page. One chunk of that work is
some UI refactoring; that could turn into rework around Cello if it's in
a suitable state.
In article <·················@newssvr13.news.prodigy.com>,
mikel <·····@evins.net> wrote:
> Kenneth Tilton wrote:
>
> [Reassurances snipped]
>
> > In article <···················@newssvr21.news.prodigy.com>,
> > mikel <·····@evins.net> wrote:
>
> Okay, I should probably get some approximately-now version of Cello and
> try it out. Remind me: where should I get it.
You'll need the cheats. :)
(a) it is under the cells project on common-lisp.net. i have yet to
arrange for eliminating the separate cello project.
(b) CVS only. Ignore anything in the FTP area
(c) grab the cell-cultures module, not the cells or cello modules. same
story.
(d) wait a bit. I am about to put a major cleanup of the ASDF and
configuration stuff (to manage all the libs <g>) which will include some
early patches from Frank's work on the OS X port.
Or just wait a while (a week?) until the OS X port is announced.
> ...One chunk of that work is
> some UI refactoring; that could turn into rework around Cello if it's in
> a suitable state.
I doubt it will be. I am just doing widgets as I need them. No doc,
either. But I am always avaiable to add missing widgets or doc.
kenny
From: Rahul Jain
Subject: Re: Lisp and GUI on Linux/Windows
Date:
Message-ID: <87lldo9bbn.fsf@nyct.net>
mikel <·····@evins.net> writes:
> Go ahead: tell me it's irrational, and Cello is the right substrate for
> Hansa2, so that I don't have to rewrite all the OSX-specific UI code for
> Windows and then once again for Linux.
You won't have to rewrite it, but it'll look identical on all the
systems. I.e., it won't use the native system's preferred toolkit, much
like Swing in Java.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> mikel <·····@evins.net> writes:
>
>
>>Go ahead: tell me it's irrational, and Cello is the right substrate for
>>Hansa2, so that I don't have to rewrite all the OSX-specific UI code for
>>Windows and then once again for Linux.
>
>
> You won't have to rewrite it, but it'll look identical on all the
> systems. I.e., it won't use the native system's preferred toolkit, much
> like Swing in Java.
Yes, I recall that from previous converstaion with Kenny. Maybe the
Hansa game UI can be game-like enough not to need native widgets; maybe
not. I haven't decided.
Kenny Tilton <·······@nyc.rr.com> writes:
> Oyvin Halfdan Thuv wrote:
>
> > mikel <·····@evins.net> writes:
> >
> >>I'm still interested in Cello on all platforms. The
> >>mass of required libraries is a little daunting, though.
> > The last point here is *very* true.
> >
>
> Cello is hard...let's go shopping!
not what I said. Cello is brilliant for me. I can get it working on my
computer and it is stable, fancy and all that. However, the more dependencies
it has, the more can go wrong on a customers computer.
Customers do not want to install a dozen packages just to install a small
program that, perhaps, need only a fraction of all the functionality of all
the pacakges it requires. Also it harms portability.
Functionality is good, but stability, portability, simplicity and size comes
first. Things like audio are nice add-ons, for example.
That said. I believe the cello project is a lot of fun, and that there is a
need for what cello provides. I have spent lots of time on getting it to work
on FreeBSD (with a free lisp implementation).
--
Oyvin
In article <··············@apollo.orakel.ntnu.no>,
Oyvin Halfdan Thuv <·····@remove.spam.oyvins.net> wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Oyvin Halfdan Thuv wrote:
> >
> > > mikel <·····@evins.net> writes:
> > >
> > >>I'm still interested in Cello on all platforms. The
> > >>mass of required libraries is a little daunting, though.
> > > The last point here is *very* true.
> > >
> >
> > Cello is hard...let's go shopping!
>
> not what I said.
Actually, I wasn't saying anything, I just loved that thread title from
a couple of years ago. I certainly agree about the libraries. Hell, I am
the one that had to pick them, build the bindings, and figure out how
they worked.
> Cello is brilliant for me. I can get it working on my
> computer ...
Congratulations. I am flabbergasted. You chalked up a Cello port on a
new OS as well as on the first ever free Lisp?
Who knew? :)
> ...and it is stable, fancy and all that. However, the more dependencies
> it has, the more can go wrong on a customers computer.
>
> Customers do not want to install a dozen packages just to install a small
> program that, perhaps, need only a fraction of all the functionality of all
> the pacakges it requires. Also it harms portability.
(a) I do not /think/ I invented the idea of library dependency. Did I?
:) But I understand: the more there are, the bigger the hassle.
(b) The design is modular, so leave out anything you do not need. The
modularity should also help those who wish to replace one library with
another. But mostly....
(c) Think of Cello as a proof of concept, not a final product. Those
libraries are how one open source fairy managed to get all that
functionality into Cello in relatively short order. The idea is to get
something (a) portable and (b) of significant value (c) working so...
... hordes of admirers drawn in by the cool functionality can translate
Freeglut into CL. FTGL would be a breeze (to fork to CL), Freetype I
think should stay Freetype. Perhaps Edi's graphics package could replace
ImageGraphicks. OpenGL and OpenAL should stay. Something like that. But
this fairy has only two wings, I cannot do everything.
(d) yes, an installer will be a good idea. :)
>
> Functionality is good, but stability, portability, simplicity and size comes
> first. Things like audio are nice add-ons, for example.
>
> That said. I believe the cello project is a lot of fun, and that there is a
> need for what cello provides. I have spent lots of time on getting it to work
> on FreeBSD (with a free lisp implementation).
Fascinating. You actually have the groovy Light Panel working on FreeBSD
and CMUCL or SBCL (or ?)?
speechlessly yours,
kenny
Kenneth Tilton <·······@nyc.rr.com> writes:
> > need for what cello provides. I have spent lots of time on getting it to work
> > on FreeBSD (with a free lisp implementation).
>
> Fascinating. You actually have the groovy Light Panel working on FreeBSD
> and CMUCL or SBCL (or ?)?
Hm, I should perhaps state this clearer: I spent a lot of time _trying_ to
get it to work on FreeBSD. I only partially succeded (works in parts on ACL).
The windows version was easy enough, and seemed to work well. I haven't played
with it for some time now, because of time-strain and a thousand other
projects I'm playing with. Perhaps I will look into it soon (tm).
I think the idea of cello is brilliant though, but with all the (heavy)
dependencies I takes more time than I have to get it running on a new platform.
--
Oyvin
Andrei Stebkov <········@tht.net> writes:
> I heard something about CLIM, GTK and TK bindings for CL but couldn't find
> any comprehensible manuals/tutorials on these libs.
My blog:
http://www.paoloamoroso.it/log (aggregated by http://planet.lisp.org )
frequently covers CLIM.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface