So, what do people use to build text based menu systems, and to do other
terminal based maneuvers in lisp? In C I would reach for curses, but
what now? Any hints?
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Sun, 30 Dec 2007 06:06:09 +0100, Andreas Davour wrote:
>
> So, what do people use to build text based menu systems, and to do other
> terminal based maneuvers in lisp? In C I would reach for curses, but
> what now? Any hints?
>
> /Andreas
Ncurses through CFFI. I've got partial bindings that I expand when
necessary. I believe there's some bindings called cl-ncurses floating
around the net, but they were buggy when I tried them. I don't remember
what sort of bug it was.
Paul Donnelly <·············@sbcglobal.net> writes:
> On Sun, 30 Dec 2007 06:06:09 +0100, Andreas Davour wrote:
>
>>
>> So, what do people use to build text based menu systems, and to do other
>> terminal based maneuvers in lisp? In C I would reach for curses, but
>> what now? Any hints?
>>
>
> Ncurses through CFFI. I've got partial bindings that I expand when
> necessary. I believe there's some bindings called cl-ncurses floating
> around the net, but they were buggy when I tried them. I don't remember
> what sort of bug it was.
So there is no native solution? I'll be ready for bugs. Thanks.
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Sun, 30 Dec 2007 06:06:09 +0100, Andreas Davour
<·······@updateLIKE.uu.HELLse> tried to confuse everyone with this message:
>
>So, what do people use to build text based menu systems, and to do other
>terminal based maneuvers in lisp? In C I would reach for curses, but
>what now? Any hints?
Use CFFI to call Ncurses _or_ PDcurses (to cover non-Linux systems). A
reasonably useful implementation can be found here:
http://common-lisp.net/project/lifp/sewers-src.zip
(check out curses.lisp; it also contains some bloat such as REPL
implementation; oh, there is also a whole game that uses the library)
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
····@mail.ru (Timofei Shatrov) writes:
> On Sun, 30 Dec 2007 06:06:09 +0100, Andreas Davour
> <·······@updateLIKE.uu.HELLse> tried to confuse everyone with this message:
>
>>
>>So, what do people use to build text based menu systems, and to do other
>>terminal based maneuvers in lisp? In C I would reach for curses, but
>>what now? Any hints?
>
> Use CFFI to call Ncurses _or_ PDcurses (to cover non-Linux systems). A
> reasonably useful implementation can be found here:
>
> http://common-lisp.net/project/lifp/sewers-src.zip
>
> (check out curses.lisp; it also contains some bloat such as REPL
> implementation; oh, there is also a whole game that uses the library)
Ouch! I sense a lack, or maybe I'm into unidiomatic territory.
Thanks.
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Sun, 30 Dec 2007 15:42:30 +0100, Andreas Davour
<·······@updateLIKE.uu.HELLse> tried to confuse everyone with this message:
>····@mail.ru (Timofei Shatrov) writes:
>
>> On Sun, 30 Dec 2007 06:06:09 +0100, Andreas Davour
>> <·······@updateLIKE.uu.HELLse> tried to confuse everyone with this message:
>>
>>>
>>>So, what do people use to build text based menu systems, and to do other
>>>terminal based maneuvers in lisp? In C I would reach for curses, but
>>>what now? Any hints?
>>
>> Use CFFI to call Ncurses _or_ PDcurses (to cover non-Linux systems). A
>> reasonably useful implementation can be found here:
>>
>> http://common-lisp.net/project/lifp/sewers-src.zip
>>
>> (check out curses.lisp; it also contains some bloat such as REPL
>> implementation; oh, there is also a whole game that uses the library)
>
>Ouch! I sense a lack, or maybe I'm into unidiomatic territory.
>
I don't see how Lisp is different from C in this case. In either case you have
to call some external library. The fact that curses implementations are written
in C doesn't matter. This is extremely low-level OS-specific stuff, and perhaps
C is the best language to implement that stuff in. Once you have FFI bindings,
curses is just as easy and natural to use in Lisp as in C.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
····@mail.ru (Timofei Shatrov) writes:
>>> (check out curses.lisp; it also contains some bloat such as REPL
>>> implementation; oh, there is also a whole game that uses the library)
>>
>>Ouch! I sense a lack, or maybe I'm into unidiomatic territory.
>
> I don't see how Lisp is different from C in this case. In either case
> you have to call some external library. The fact that curses
> implementations are written in C doesn't matter. This is extremely
> low-level OS-specific stuff, and perhaps C is the best language to
> implement that stuff in. Once you have FFI bindings, curses is just as
> easy and natural to use in Lisp as in C.
If you have to use FFI it usually means two things. First you've
encountered one of the things that Lisp lack, like a standard socket
library, or second that you are trying to do things the C way and not the
Lisp way. If during all these years nobody have made any terminal
handling library I'm beginning to think I'm onto case two.
As it is low-level stuff I guess FFI is the way to go, but I'm beginning
to wonder how lispers do their (G)UI programming anyway.
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
From: Peter Hildebrandt
Subject: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <op.t37ld3x0x6i8pv@babyfoot>
On Mon, 31 Dec 2007 16:20:33 +0100, Andreas Davour
<·······@updatelike.uu.hellse> wrote:
> As it is low-level stuff I guess FFI is the way to go, but I'm beginning
> to wonder how lispers do their (G)UI programming anyway.
I've been wondering about this for a while. For most environments there
seem to be canonical triples of platform, language, and library that
people use (for instance Linux-C-GTK, Linux-Python-PyGTK,
Windows-C++-MSVC, Windows-C#-.NET, etc).
But what do lispers use who work on real applications that are not
implemented as web-services? Do they just fall back to the command line?
The reason I'm asking is that I am working on a project which relies
heavily on a dynamic, interactive GUI. I am aware that I will need
non-standard functionality, and I am willing to put in some effort to
extend the toolkit to meet my needs. However, after looking at the
various options I find it very hard to judge which one is a good choice to
build on. I should add that I am quite new to the lisp world, so please
correct me if I am missing something obvious. To an outsider the GUI
toolkit landscape for lisp is a little ... err ... confusing.
My wish list goes like this:
- available on linux
- lispy interface (a dynamic application should be met by a dynamic UI
toolkit), preferrably Cells Inside
- open source (I want to see how it works and submit patches if necessary)
- native looks, preferrably GTK or QT, because I'd like my users to enjoy
a modern standard look and feel (in particular I do not enjoy the hard
edged appearance of tk on linux (I know that one can use skins for tk, but
I don't want my users to have to deal with this)
I found the following options:
(1) McCLIM
From the facts, McCLIM appears the way to go -- except for its looks and
its speed (it feels quite slow on my 1.4 GHz Pentium M laptop, especially
with the gtkairo backend)
(2) The libraries of their commercial environment (CAPI etc.)
I'd prefer to stay with free libraries and not be dependent on a specific
vendor
(3) One of the various FFIs (lambda-gtk etc.)
They pave the way for native UIs, but the code becomes quite Cish. I'd
end up writing a thick abstraction layer to prevent my application from
being contaminated with FFI calls.
(4) A lispy GUI wrapper (cells-gtk, celtk, cello, LTK)
That'd be the perfect solution (lisp on the inside -- native UI on the
outside), but I have the impression that the community around celtk,
cells-gtk, and cello is rather small (judging by the traffic on the
mailing lists). LTK and celtk are based on tk and look unpleasant on
linux. Cello is very much work in progress. cells-gtk cvs has not been
updated since June 2006.
So far I have been using cells-gtk (and put together two patches), but I
wonder whether I should rather invest time and effort into a different
project. I believe there must be other people out there who need a
lisp-like, dynamic, interactive, yet modern/native-looking GUI.
So what do they do? What am I missing?
Happy new year everybody, and I am looking forward to your answers.
Peter
>
> /Andreas
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Dec 31, 11:57 am, "Peter Hildebrandt" <·················@gmail.com>
wrote:
>
> (4) A lispy GUI wrapper (cells-gtk, celtk, cello, LTK)
I use LTK for my Lisp GUI needs, personally. When I use a GUI toolkit
in Lisp, it is usually to create a simple tool for end-users to do
something well, er.. dumb. I could easily do most of this in bash with
xdialog. I use Lisp since its easier for me to figure out what I was
doing 3 months later (no pipe stream filters to grok). I don't deploy
such tools on Linux, so the Tk look on Linux isn't an issue - it looks
just fine on Mac and Windows.
However, there is a tool called gtk-server that is quite nice. It is,
as its name implies, a server process which accepts connections over
TCP/IP. You feed it ASCII, and it draws widgets. It can also be used
over a pipe. I have some partial code to use gtk-server from CMUCL
somewhere. I can try to dig it up if you'd like to take a look, but it
was quite easy to do. I abandoned it when I found LTK.
-M
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <op.t4axrxncx6i8pv@babyfoot>
On Mon, 31 Dec 2007 21:55:56 +0100, Mike G. <···············@gmail.com>
wrote:
> I use LTK for my Lisp GUI needs, personally. When I use a GUI toolkit
> in Lisp, it is usually to create a simple tool for end-users to do
> something well, er.. dumb. I could easily do most of this in bash with
> xdialog. I use Lisp since its easier for me to figure out what I was
> doing 3 months later (no pipe stream filters to grok).
I did the same -- until I have taken up a project for which I need more
than that, which is why I am asking here. After considering the
alternatives for a while I chose cells-gtk about eight months ago, because
it appeared to be the best fit to what I was doing. During the last two
months or so I wrote a few extensions to cells-gtk, and now I find myself
wondering whether (a) this is anything of general interest, (b) everybody
else uses solution X which already provides everything I am reinventing,
or (c) no one is interested.
> I don't deploy
> such tools on Linux, so the Tk look on Linux isn't an issue - it looks
> just fine on Mac and Windows.
That's true. I will also look into tcl8.5 and tile (which Kenny Tilton
and David Golden pointed out).
> However, there is a tool called gtk-server that is quite nice. It is,
> as its name implies, a server process which accepts connections over
> TCP/IP. You feed it ASCII, and it draws widgets. It can also be used
> over a pipe. I have some partial code to use gtk-server from CMUCL
> somewhere. I can try to dig it up if you'd like to take a look, but it
> was quite easy to do. I abandoned it when I found LTK.
Thanks for the offer, but I'm afraid that would not help. It looks like
cells-gtk or celtk + tcl8.5 are closer to what I am looking for.
Peter
> -M
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Paul Tarvydas
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <flgcjq$kb2$1@aioe.org>
Our visual programming product uses Lispworks GP (and some CAPI), along with
a (free) prolog-written-in-lisp. The diagrams are edited in an
emacs-for-2d-diagram-like editor and are broken down into simple "facts"
(prolog assertions), e.g. something like "(line id x y)". Prolog-ish rules
parse and compile the diagrams to code ("parse + compile" == prolog
inferencing).
The printing product has a page-layout gui built mostly with Lispworks GP
(and soon-to-exist state machines - what you really need for GUI
programming). I'm not sure why I didn't use CAPI, other than I needed
intimate under-the-hood control. I didn't use Tk for the same reason (not
written in lisp, less under-the-hood control). If I didn't have an
insanely tight deadline, I would have explored Cells or our own visual
programming language, above (which doesn't have a library of gui
components - i.e. a "research" project).
pt
From: Paul Tarvydas
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <flgj3f$7pl$1@aioe.org>
I forgot to add - we often use S/SL (Syntax Semantic Language - Holt, et
al), much in the same way that lispers use macros and in the same way that
physicists invent notations - to define new sub-languages that express
problems and solutions within the problem domain. We use S/SL when
defining such a full-blown language (something I doubt that I would use
lisp macros for).
pt
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <op.t4c2er2ox6i8pv@babyfoot>
On Wed, 02 Jan 2008 17:04:40 +0100, Paul Tarvydas
<········@visualframeworksinc.com> wrote:
> Our visual programming product uses Lispworks GP (and some CAPI), along
> with
> a (free) prolog-written-in-lisp. The diagrams are edited in an
> emacs-for-2d-diagram-like editor and are broken down into simple "facts"
> (prolog assertions), e.g. something like "(line id x y)". Prolog-ish
> rules
> parse and compile the diagrams to code ("parse + compile" == prolog
> inferencing).
Wow, that's an interesting approach. Without to much understanding, it
feels this is similar to the declarative approach in cells-gtk/celtk,
except more explicit (due to the declarations not being intermingled with
object oriented stuff). Does that make sense at all?
> The printing product has a page-layout gui built mostly with Lispworks GP
> (and soon-to-exist state machines - what you really need for GUI
> programming). I'm not sure why I didn't use CAPI, other than I needed
> intimate under-the-hood control.
It's interesting you are the first one here to mention a commercial
product. I would have guessed that most serious programmers go with the
commercial libraries. Maybe this is because "most serious programmers"
don't post on c.l.l (as Edi pointed out in another thread).
> I didn't use Tk for the same reason (not
> written in lisp, less under-the-hood control). If I didn't have an
> insanely tight deadline, I would have explored Cells or our own visual
> programming language, above (which doesn't have a library of gui
> components - i.e. a "research" project).
In other words, if time would not have been an issue you would have
preferred your homegrown project or a free solution over Lispworks
GP/CAPI? I'm asking this since I am wondering whether going with a
commercial library would be worth the effort, or whether the time is
better spent improving an open source project such as cells-gtk.
Peter
> pt
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Paul Tarvydas
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <flj47g$77r$1@aioe.org>
Peter Hildebrandt wrote:
> On Wed, 02 Jan 2008 17:04:40 +0100, Paul Tarvydas
> <········@visualframeworksinc.com> wrote:
>
>> Our visual programming product uses Lispworks GP (and some CAPI), along
>> with
>> a (free) prolog-written-in-lisp. The diagrams are edited in an
>> emacs-for-2d-diagram-like editor and are broken down into simple "facts"
>> (prolog assertions), e.g. something like "(line id x y)". Prolog-ish
>> rules
>> parse and compile the diagrams to code ("parse + compile" == prolog
>> inferencing).
>
> Wow, that's an interesting approach. Without to much understanding, it
> feels this is similar to the declarative approach in cells-gtk/celtk,
> except more explicit (due to the declarations not being intermingled with
> object oriented stuff). Does that make sense at all?
Actually, I'm not sure which technology you are referring to. The visual
technology or the CL used to implement the visual editor+compiler? I'll
answer both questions ...
The visual tool uses consistent, compilable (hence, strongly typed) diagrams
to express software architectures. Instead of using the UML approach
(everything plus the kitchen sink), we stripped the visual components down
to their simplest form and allow them to communicate only via "events".
The result is architectural components which are all asynchronous (think
very cheap "processes") and a way to draw diagrams of architectures which,
I believe, does not exist in any other practical (software) language.
Yes, "events" and "cells" and smalltalk "listener" do-hickeys share a common
meme.
The prolog-like CL technology that we used to implement the graphical editor
is neat, also. When we built the first few versions of the visual tool, we
simply used the common editing "gestures" known to anyone who has used
Paint, Visio, etc, etc. We found that that form of visual editing sucks -
esp. when you insist on using diagrams as syntax for a programming
language. You must have a "programmer's editor" (e.g. emacs) for diagrams
if you are going to use diagrams as syntax.
So, we had to invent a new visual editor - essentially a research project.
Having run across "factbases" in other projects and being impressed with
their simplicity, and, knowing that we didn't know what the final form of
the research-y visual editor would be, we used factbases to implement the
editor. A factbase is, in essence, a collection of prolog assertions, at a
very low level - e.g. we literally describe a visual rectangular "box" as a
set of lines, then use prolog-ish rules to infer that the lines intersect
to form a closed figure. I.E. the graphical primitives that the editor
supports are: straight lines, crooked lines (beziers), directional lines
(start-at x,y, end-at x,y), snippets of text, circles and crooked circles
(ellipses), cut/copy/paste. This visual syntax is "parsed" and
semantically analyzed using backtracking rules (which is the same as an
NFA, upon which YACC and friends are based (they constrain the NFA to be
PDFA)). The small set of editing gestures are combined using "scripts"
(CL) to construct more interesting editing gestures. There exists the
concept of "point" and "mark". All visual editing can be done from the
keyboard (up-arrow moves "mark", shift-up-arrow moves "point", control-L
constructs a line from "point" to "mark", and so on). Editing gestures can
also be assigned to the mouse, using scripts.
>
>> The printing product has a page-layout gui built mostly with Lispworks GP
>> (and soon-to-exist state machines - what you really need for GUI
>> programming). I'm not sure why I didn't use CAPI, other than I needed
>> intimate under-the-hood control.
>
> It's interesting you are the first one here to mention a commercial
> product. I would have guessed that most serious programmers go with the
> commercial libraries. Maybe this is because "most serious programmers"
> don't post on c.l.l (as Edi pointed out in another thread).
In fact, there is more "commercial" activity on the Lispworks mailing list
than on c.l.l.
Yes, because I'm working on commercial products, I felt it prudent to use
a "supported" commercial lisp. When it was decision time, the licensing
options made it a no-brainer to choose Lispworks, for us (we also do
consulting, in which case we sometimes "give away" the final program .exe
to the OEM customer who "give it away" to their customers, which prevented
us from choosing anything with a royalty-based license).
Beyond this, Lispworks also offers: (a) .exe creation, (b) portability - I
can develop under linux (my preference), then port to Windows (customers'
preference) with very little trouble.
>
>> I didn't use Tk for the same reason (not
>> written in lisp, less under-the-hood control). If I didn't have an
>> insanely tight deadline, I would have explored Cells or our own visual
>> programming language, above (which doesn't have a library of gui
>> components - i.e. a "research" project).
>
> In other words, if time would not have been an issue you would have
> preferred your homegrown project or a free solution over Lispworks
> GP/CAPI? I'm asking this since I am wondering whether going with a
> commercial library would be worth the effort, or whether the time is
> better spent improving an open source project such as cells-gtk.
(A) I would choose our visual, event-based, reactive language, over anything
except that there would be a few months of ramp-up time to build enough
software GUI components to be productive. Since no one has ever built GUI
components in the reactive paradigm (other than the few we've built), that
sub-project is "research" and not schedulable.
(B) Failing that, the similarity of Cells to our event-base stuff intrigues
me and I would explore it. I looked at Cells a couple of years ago, but it
was a "researchy" project back then (similar to point A - certainly
possible to implement, but a number of unknowns (for me)).
(C) In all of the decades that I've been waiting to see a sensible approach
to graphics and GUIs, I have been most impressed with the Tk paradigm - it
seems to be the least stupid. I simply cannot stomach, though, the idea of
shipping a product where the GUI is built using Windows processes and
inter-process communication using strings between an interpret written in C
and a controller written in Lisp. It's asking for trouble - non-tech users
find all sorts of ways to break products. Sticking the above ipc mechanism
in their way simply adds yet another dimension for trouble.
I would be SO much happier if someone implemented all of Tk in CL. Either
that, or if CAPI+GP were put in the "public" domain making it the UI of
choice for Cl'ers...
(D) I have to hit a trade show at the end of Feb. I already know GP (and
CAPI) well enough (due to implementation of visual language above) to
understand the tasks that I need to complete before end-of-Feb. No time
for further experimentation or unknowns ...
pt
From: Andrew Reilly
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <5u1gm5F1fr0c8U1@mid.individual.net>
On Wed, 02 Jan 2008 13:17:47 +0100, Peter Hildebrandt wrote:
> Thanks for the offer, but I'm afraid that would not help. It looks like
> cells-gtk or celtk + tcl8.5 are closer to what I am looking for.
Sorry if I missed a counter-argument up-stream, but I have to suspect
that one of the reasons for the existence of the Armed Bear CL
implementation is to get easy access to the Java/Swing GUI libraries. Is
that not an option? (Not that there's anything necessarily wrong with tk
in one form or another...)
I hate writing GUIs, myself. I had more fun sending control codes to a
Tek 4??? graphics terminal, in days of yore. Don't seem to be able to
work that way any more...
Cheers,
--
Andrew
On Jan 2, 8:08 am, Andrew Reilly <···············@areilly.bpc-
users.org> wrote:
> On Wed, 02 Jan 2008 13:17:47 +0100, Peter Hildebrandt wrote:
> > Thanks for the offer, but I'm afraid that would not help. It looks like
> > cells-gtk or celtk + tcl8.5 are closer to what I am looking for.
>
> Sorry if I missed a counter-argument up-stream, but I have to suspect
> that one of the reasons for the existence of the Armed Bear CL
> implementation is to get easy access to the Java/Swing GUI libraries. Is
> that not an option? (Not that there's anything necessarily wrong with tk
> in one form or another...)
>
> I hate writing GUIs, myself. I had more fun sending control codes to a
> Tek 4??? graphics terminal, in days of yore. Don't seem to be able to
> work that way any more...
>
> Cheers,
>
> --
> Andrew
xterm supports Tek graphics :)
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <op.t4a5p8l1x6i8pv@babyfoot>
On Wed, 02 Jan 2008 14:08:21 +0100, Andrew Reilly
<···············@areilly.bpc-users.org> wrote:
> On Wed, 02 Jan 2008 13:17:47 +0100, Peter Hildebrandt wrote:
>
>> Thanks for the offer, but I'm afraid that would not help. It looks like
>> cells-gtk or celtk + tcl8.5 are closer to what I am looking for.
>
> Sorry if I missed a counter-argument up-stream, but I have to suspect
> that one of the reasons for the existence of the Armed Bear CL
> implementation is to get easy access to the Java/Swing GUI libraries. Is
> that not an option? (Not that there's anything necessarily wrong with tk
> in one form or another...)
I had ovelooked that one, too. Thanks for pointing it out (it is great to
be able to tap into all that experience here on c.l.l)
As to the counter argument:
> I hate writing GUIs, myself.
There ya go. From my experience with Java/Swing, coding GUIs that way is
not exactly fun. I suspect that lisp access to those libraries makes your
lisp code look like a java/swing stuff. I am afraid I was a littel fuzzy
about that in my "wish list": By "a lispy interface" I meant the toolkit
should leave my lisp application as it is, just somehow magically attach a
GUI to it. And not force me to rewrite it all around the GUI, as it seems
to be the case in Java/Swing, C/GTK, C++/MSVC, ...
My personal conclusion is that the fun is with cells-gtk (with some extra
work) or celtk (with tcl8.5), since cells appears to be the lispiest way
so far to do GUI stuff.
Peter
> I had more fun sending control codes to a
> Tek 4??? graphics terminal, in days of yore. Don't seem to be able to
> work that way any more...
>
> Cheers,
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Ken Tilton
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <47793f8a$0$13810$607ed4bc@cv.net>
Peter Hildebrandt wrote:
> On Mon, 31 Dec 2007 16:20:33 +0100, Andreas Davour
> <·······@updatelike.uu.hellse> wrote:
>
>> As it is low-level stuff I guess FFI is the way to go, but I'm beginning
>> to wonder how lispers do their (G)UI programming anyway.
You skipped the first two questions: how many lispers program at all in
lisp, and how many of those do GUI programming. Now that we are down to
a sample size we can manage on two hands...
> I've been wondering about this for a while. For most environments
> there seem to be canonical triples of platform, language, and library
> that people use (for instance Linux-C-GTK, Linux-Python-PyGTK,
> Windows-C++-MSVC, Windows-C#-.NET, etc).
...we know why no triple has been crowned "standard", and know also the
search must end in vain -- not enough users, and with everyone going
interwebby these days it could be a while before that happens.
>
> To an outsider
> the GUI toolkit landscape for lisp is a little ... err ... confusing.
I would have said "missing".
>
> My wish list goes like this:
>
> - available on linux
> - lispy interface (a dynamic application should be met by a dynamic UI
> toolkit), preferrably Cells Inside
> - open source (I want to see how it works and submit patches if necessary)
> - native looks, preferrably GTK or QT, because I'd like my users to
> enjoy a modern standard look and feel (in particular I do not enjoy
> the hard edged appearance of tk on linux (I know that one can use skins
> for tk, but I don't want my users to have to deal with this)
Has the new Tile package helped any? I understand their Prime Directive
is to look better and more native.
>
> So what do they do? What am I missing?
I am reminded of the time I was driving to a party with a navigator in
the passenger seat who had received the Original Transmission of
directions. Following the guidance she read from her notes we were soon
heading straight up a mountain on a sliver of a road steepening more and
more as first dwellings then lights and then pavement itself disappeared
leaving us on a dirt road which degraded steadily until we were jolting
and lurching up ruts and boulders and I cut in the 4WD and concluded we
had gone astray. With no argument from my navigator I suggested we would
need to call our host for new directions and this being long before the
days of the glorious cell with no little difficulty I effected a U-turn
and we worked our way back down the mountain to the main road to search
for a pay phone. Regaining the main road, my navigator complained that
we must have been on the right road and should have continued, seeing
again an unmistakeable marker corresponding to something in her notes.
No way, I said. If that was the right road they would have warned us
that we would think we had gone the wrong way.
Oh, she replied. They said that.
The information you are missing is that your experience with cells-gtk
is indeed the canonical Lisp GUI experience and precisely how that
experience will change: hard-charging newbies such as yourself landing
in Lispville dumbfounded by all the dust, cobwebs, rust, and neglect
giving the boot to the war-weary, disheartened, parentheses-mocked old
soldiers rolling up your sleeves and setting about dragging the damn
language out of the seventies and into the 21st century just in time for
the asteroid to hit. What was the question?
kzo
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <op.t4axf8pxx6i8pv@babyfoot>
On Mon, 31 Dec 2007 20:15:21 +0100, Ken Tilton <···········@optonline.net>
wrote:
> You skipped the first two questions: how many lispers program at all in
> lisp, and how many of those do GUI programming. Now that we are down to
> a sample size we can manage on two hands...
The question here is, of course, what is source and what is effect. Is
there no common GUI library because no one wants to write GUI applications
in lisp, or does no one write GUI applications in lisp because there seems
to be no good way to do it?
>> To an outsider
>> the GUI toolkit landscape for lisp is a little ... err ... confusing.
> I would have said "missing".
Thanks for the clear statement. I had the same impression, but as a
newcomer it is not my place to make this kind of statement. If anything,
this means I am not completely reinventing the wheel when improving
cells-gtk. ;-)
>> - native looks, preferrably GTK or QT, because I'd like my users to
>> enjoy a modern standard look and feel (in particular I do not enjoy
>> the hard edged appearance of tk on linux (I know that one can use
>> skins for tk, but I don't want my users to have to deal with this)
>
> Has the new Tile package helped any? I understand their Prime Directive
> is to look better and more native.
David Golden wrote about this in more detail. I'll put my answer in the
reply to his post.
>> So what do they do? What am I missing?
>
> I am reminded of the time I was driving to a party with a navigator in
> the passenger seat who had received the Original Transmission of
> directions. Following the guidance she read from her notes we were soon
> heading straight up a mountain on a sliver of a road steepening more and
> more as first dwellings then lights and then pavement itself disappeared
> leaving us on a dirt road which degraded steadily until we were jolting
> and lurching up ruts and boulders and I cut in the 4WD and concluded we
> had gone astray. With no argument from my navigator I suggested we would
> need to call our host for new directions and this being long before the
> days of the glorious cell with no little difficulty I effected a U-turn
> and we worked our way back down the mountain to the main road to search
> for a pay phone. Regaining the main road, my navigator complained that
> we must have been on the right road and should have continued, seeing
> again an unmistakeable marker corresponding to something in her notes.
>
> No way, I said. If that was the right road they would have warned us
> that we would think we had gone the wrong way.
>
> Oh, she replied. They said that.
That's a beautiful metaphor. Maybe you should aim for a second career
writing prose instead of code. I'd love to read this in a book on lisp
programming :-)
> The information you are missing is that your experience with cells-gtk
> is indeed the canonical Lisp GUI experience and precisely how that
> experience will change: hard-charging newbies such as yourself landing
> in Lispville dumbfounded by all the dust, cobwebs, rust, and neglect
> giving the boot to the war-weary, disheartened, parentheses-mocked old
> soldiers rolling up your sleeves and setting about dragging the damn
> language out of the seventies and into the 21st century just in time for
> the asteroid to hit. What was the question?
I'm confused.
(a) Newbies in their foolish ways mistake the lisp way of doing things for
old-fashionedness. They set about to "fixing" things by reinventing the
wheel. I should stay away from the problem until I have seen the light.
(b) I should get back to work realizing my idea of a GUI toolkit and there
will be light at the end of the tunnel
(a) or (b), which one is your point?
Peter
> kzo
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Ken Tilton
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <477b9387$0$13840$607ed4bc@cv.net>
Peter Hildebrandt wrote:
> On Mon, 31 Dec 2007 20:15:21 +0100, Ken Tilton
> <···········@optonline.net> wrote:
>
>> You skipped the first two questions: how many lispers program at all
>> in lisp, and how many of those do GUI programming. Now that we are
>> down to a sample size we can manage on two hands...
>
>
> The question here is, of course, what is source and what is effect. Is
> there no common GUI library because no one wants to write GUI
> applications in lisp, or does no one write GUI applications in lisp
> because there seems to be no good way to do it?
The former. Recall that nice packages like LTk and Cells-Gtk seem dead
to you because of the paucity of activity on their lists. No one was
waiting for a Lisp GUI, or if they were they are all now waiting for a
Lisp Web platform. Understandable, but Peter Herth and I threw GUI
parties and no one came. Recall also that there is barely anyone doing
anything more than hobby Lisping, so it is really no surprise.
>
>>> To an outsider
>>> the GUI toolkit landscape for lisp is a little ... err ... confusing.
>>
>> I would have said "missing".
>
>
> Thanks for the clear statement. I had the same impression, but as a
> newcomer it is not my place to make this kind of statement. If
> anything, this means I am not completely reinventing the wheel when
> improving cells-gtk. ;-)
>
>>> - native looks, preferrably GTK or QT, because I'd like my users to
>>> enjoy a modern standard look and feel (in particular I do not
>>> enjoy the hard edged appearance of tk on linux (I know that one can
>>> use skins for tk, but I don't want my users to have to deal with this)
>>
>>
>> Has the new Tile package helped any? I understand their Prime
>> Directive is to look better and more native.
>
>
> David Golden wrote about this in more detail. I'll put my answer in
> the reply to his post.
>
>>> So what do they do? What am I missing?
>>
>>
>> I am reminded of the time I was driving to a party with a navigator
>> in the passenger seat who had received the Original Transmission of
>> directions. Following the guidance she read from her notes we were
>> soon heading straight up a mountain on a sliver of a road steepening
>> more and more as first dwellings then lights and then pavement itself
>> disappeared leaving us on a dirt road which degraded steadily until
>> we were jolting and lurching up ruts and boulders and I cut in the
>> 4WD and concluded we had gone astray. With no argument from my
>> navigator I suggested we would need to call our host for new
>> directions and this being long before the days of the glorious cell
>> with no little difficulty I effected a U-turn and we worked our way
>> back down the mountain to the main road to search for a pay phone.
>> Regaining the main road, my navigator complained that we must have
>> been on the right road and should have continued, seeing again an
>> unmistakeable marker corresponding to something in her notes.
>>
>> No way, I said. If that was the right road they would have warned us
>> that we would think we had gone the wrong way.
>>
>> Oh, she replied. They said that.
>
>
> That's a beautiful metaphor. Maybe you should aim for a second career
> writing prose instead of code. I'd love to read this in a book on lisp
> programming :-)
Thanks! I am looking at standup so I can costar with Jessica Alba someday.
>
>> The information you are missing is that your experience with
>> cells-gtk is indeed the canonical Lisp GUI experience and precisely
>> how that experience will change: hard-charging newbies such as
>> yourself landing in Lispville dumbfounded by all the dust, cobwebs,
>> rust, and neglect giving the boot to the war-weary, disheartened,
>> parentheses-mocked old soldiers rolling up your sleeves and setting
>> about dragging the damn language out of the seventies and into the
>> 21st century just in time for the asteroid to hit. What was the
>> question?
>
>
> I'm confused.
>
> (a) Newbies in their foolish ways mistake the lisp way of doing things
> for old-fashionedness. They set about to "fixing" things by
> reinventing the wheel. I should stay away from the problem until I
> have seen the light.
I see. Yes, this newby bull in a china shop scenario often happens,
usually having to do with the parentheses. But in this case new, fresh
blood is exactly what Lisp needs and has long been my prediction, namely
that noobs would arrive on our shores, love the language, bemoan the
rest and set about dragging lisp into the, well, nineties. In a sense
this is where Cells and Celtk and Cello came from, me a 1995 noob being
someone interested in getting some actual work done. It also explains
why I am the only Lisper who sees Emacs+Slime as a joke of an IDE.
>
> (b) I should get back to work realizing my idea of a GUI toolkit and
> there will be light at the end of the tunnel
>
> (a) or (b), which one is your point?
My prose was lacking. (b) is closer, but I am saying you are the light,
the fresh troops parachuting in to relieve the old.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
>> I'm confused.
>>
>> (a) Newbies in their foolish ways mistake the lisp way of doing
>> things for old-fashionedness. They set about to "fixing" things by
>> reinventing the wheel. I should stay away from the problem until I
>> have seen the light.
>
> I see. Yes, this newby bull in a china shop scenario often happens,
> usually having to do with the parentheses. But in this case new, fresh
> blood is exactly what Lisp needs and has long been my prediction,
> namely that noobs would arrive on our shores, love the language,
> bemoan the rest and set about dragging lisp into the, well,
> nineties. In a sense this is where Cells and Celtk and Cello came
> from, me a 1995 noob being someone interested in getting some actual
> work done. It also explains why I am the only Lisper who sees
> Emacs+Slime as a joke of an IDE.
May I ask what you use and prefer? Just curious. I'm not sure in which
century I'm living really considering the kind of user interfaces I've
been known to use and prefer. :-)
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Andreas Davour wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>>I'm confused.
>>>
>>>(a) Newbies in their foolish ways mistake the lisp way of doing
>>>things for old-fashionedness. They set about to "fixing" things by
>>>reinventing the wheel. I should stay away from the problem until I
>>>have seen the light.
>>
>>I see. Yes, this newby bull in a china shop scenario often happens,
>>usually having to do with the parentheses. But in this case new, fresh
>>blood is exactly what Lisp needs and has long been my prediction,
>>namely that noobs would arrive on our shores, love the language,
>>bemoan the rest and set about dragging lisp into the, well,
>>nineties. In a sense this is where Cells and Celtk and Cello came
>>from, me a 1995 noob being someone interested in getting some actual
>>work done. It also explains why I am the only Lisper who sees
>>Emacs+Slime as a joke of an IDE.
>
>
> May I ask what you use and prefer? Just curious. I'm not sure in which
> century I'm living really considering the kind of user interfaces I've
> been known to use and prefer. :-)
May I ask what you are asking? Just curious. I ask because I am guessing
I use caffeine and I prefer ephedra is not the pair you seek.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> Andreas Davour wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>>
>>>>I'm confused.
>>>>
>>>>(a) Newbies in their foolish ways mistake the lisp way of doing
>>>>things for old-fashionedness. They set about to "fixing" things by
>>>>reinventing the wheel. I should stay away from the problem until I
>>>>have seen the light.
>>>
>>>I see. Yes, this newby bull in a china shop scenario often happens,
>>>usually having to do with the parentheses. But in this case new, fresh
>>>blood is exactly what Lisp needs and has long been my prediction,
>>>namely that noobs would arrive on our shores, love the language,
>>>bemoan the rest and set about dragging lisp into the, well,
>>>nineties. In a sense this is where Cells and Celtk and Cello came
>>>from, me a 1995 noob being someone interested in getting some actual
>>>work done. It also explains why I am the only Lisper who sees
>>>Emacs+Slime as a joke of an IDE.
>>
>>
>> May I ask what you use and prefer? Just curious. I'm not sure in which
>> century I'm living really considering the kind of user interfaces I've
>> been known to use and prefer. :-)
>
> May I ask what you are asking? Just curious. I ask because I am
> guessing I use caffeine and I prefer ephedra is not the pair you seek.
Well, I thought that I might learn about some IDE solution that was way
better than Slime+Emacs, but since Edi thinks your preference is easy to
find and I'm really satisfied with Slime+Emacs as an IDE I think I'll
just let it drop.
Code produced is more important than the tools used anyway.
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Andreas Davour wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Andreas Davour wrote:
>>
>>>Ken Tilton <···········@optonline.net> writes:
>>>
>>>
>>>
>>>>>I'm confused.
>>>>>
>>>>>(a) Newbies in their foolish ways mistake the lisp way of doing
>>>>>things for old-fashionedness. They set about to "fixing" things by
>>>>>reinventing the wheel. I should stay away from the problem until I
>>>>>have seen the light.
>>>>
>>>>I see. Yes, this newby bull in a china shop scenario often happens,
>>>>usually having to do with the parentheses. But in this case new, fresh
>>>>blood is exactly what Lisp needs and has long been my prediction,
>>>>namely that noobs would arrive on our shores, love the language,
>>>>bemoan the rest and set about dragging lisp into the, well,
>>>>nineties. In a sense this is where Cells and Celtk and Cello came
>>>>from, me a 1995 noob being someone interested in getting some actual
>>>>work done. It also explains why I am the only Lisper who sees
>>>>Emacs+Slime as a joke of an IDE.
>>>
>>>
>>>May I ask what you use and prefer? Just curious. I'm not sure in which
>>>century I'm living really considering the kind of user interfaces I've
>>>been known to use and prefer. :-)
>>
>>May I ask what you are asking? Just curious. I ask because I am
>>guessing I use caffeine and I prefer ephedra is not the pair you seek.
>
>
> Well, I thought that I might learn about some IDE solution that was way
> better than Slime+Emacs,...
Oh, OK. On Windows, AllegroCL. Elsewhere, the MCL IDE was pretty good.
Otherwise, it would be Emacs+AllegroCL.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Edi Weitz
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <usl12zist.fsf@agharta.de>
On Sun, 13 Jan 2008 00:49:27 +0100, Andreas Davour <·······@updateLIKE.uu.HELLse> wrote:
> May I ask what you use and prefer?
Kenny, it seems you haven't been clear enough about that in the last
years... :)
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Sun, 13 Jan 2008 00:49:27 +0100, Andreas Davour
> <·······@updateLIKE.uu.HELLse> wrote:
>
>> May I ask what you use and prefer?
>
> Kenny, it seems you haven't been clear enough about that in the last
> years... :)
Well, let's just say when I last read c.l.l regularly Erik Naggum was
still around, and google hadn't indexed it all. I had totally forgotten
I maybe could find an answer that way.
/andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
It just seems like 'if you aren't googled you don't exist' ...;-)
Cor
--
SPAM DELENDA EST http://www.clsnet.nl/mail.php
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Alle schraifvauden zijn opsettelick, teneynde ieder lafaart de cans te
gevuh over spelingk te mekkuh instede de inhaut
On Jan 13, 5:17 am, Cor <····@clsnet.nl> wrote:
> It just seems like 'if you aren't googled you don't exist' ...;-)
>
> Cor
Did you googled at all , searching for common lisp GUI returned some
good results though far from complete.
Open source has some good portable libraries based on cells:
Cells-gtk
cell-TK
cello
Lispworks has capi that has a native feel on win/linux/mac
Allegro has a nice portable GUI library
cheers
Slobodan
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5f5wiwpx6i8pv@babyfoot>
On Thu, 24 Jan 2008 19:19:28 +0100, Slobodan Blazeski
<·················@gmail.com> wrote
> Did you googled at all , searching for common lisp GUI returned some
> good results though far from complete.
Did you read the rest of this thread at all? ;-)
> Open source has some good portable libraries based on cells:
> Cells-gtk
> cell-TK
> cello
>
> Lispworks has capi that has a native feel on win/linux/mac
> Allegro has a nice portable GUI library
This list was my starting point for this thread. My question has been:
Which ones do people actually use, and how do they feel about them.
So if you have done some GUI programming in lisp yourself, it'd be great
if you would share your experience.
Peter
> cheers
> Slobodan
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Jan 24, 7:34 pm, "Peter Hildebrandt" <·················@gmail.com>
wrote:
> On Thu, 24 Jan 2008 19:19:28 +0100, Slobodan Blazeski
> <·················@gmail.com> wrote
>
> > Did you googled at all , searching for common lisp GUI returned some
> > good results though far from complete.
>
> Did you read the rest of this thread at all? ;-)
Actually no I was going for a drive by posting :)
>
> > Open source has some good portable libraries based on cells:
> > Cells-gtk
> > cell-TK
> > cello
>
> > Lispworks has capi that has a native feel on win/linux/mac
> > Allegro has a nice portable GUI library
>
> This list was my starting point for this thread. My question has been:
> Which ones do people actually use, and how do they feel about them.
>
> So if you have done some GUI programming in lisp yourself, it'd be great
> if you would share your experience.
I've tried CAPI & Allegro library, but switched completely to web.
CAPI has a native look on windows, linux and mac. Both are easy to
learn. Allegro lib appears sort of CLOSish, that might be good or bad
depending of your point of view.
So If you're interested in buying commercial lisp you can walk
through their tutorials in few hours and get a better feeling of what
you're going to work with than anyone could tell you.
cheers
Slobodan
>
> Peter
>
> > cheers
> > Slobodan
>
> --
> Using Opera's revolutionary e-mail client:http://www.opera.com/mail/
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5hzqag8x6i8pv@babyfoot>
On Thu, 24 Jan 2008 23:23:35 +0100, Slobodan Blazeski
<·················@gmail.com> wrote:
>> > Did you googled at all , searching for common lisp GUI returned some
>> > good results though far from complete.
>> Did you read the rest of this thread at all? ;-)
> Actually no I was going for a drive by posting :)
Gotcha.
>> So if you have done some GUI programming in lisp yourself, it'd be great
>> if you would share your experience.
> I've tried CAPI & Allegro library, but switched completely to web.
> CAPI has a native look on windows, linux and mac. Both are easy to
> learn. Allegro lib appears sort of CLOSish, that might be good or bad
> depending of your point of view.
> So If you're interested in buying commercial lisp you can walk
> through their tutorials in few hours and get a better feeling of what
> you're going to work with than anyone could tell you.
Alright. Actually this is what I have been waiting for. Given that the
open source libs are only suitable for small apps, still under
development, and/or tricky to set up, I figured I would be pointed to the
commercial libs sooner or later. I do not have the time at this point to
evaluate them carefully, so I hoped someone who had done so would tell me
how useful (or not) they are.
I take it from yours and John's post that both Lispworks and Allegro have
good solutions to offer, so if I ever get tired of hacking cells-gtk, I
know where to go.
For now I'm having way too much fun with a cells driven gui :-)
Peter.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Jan 25, 7:16 pm, "Peter Hildebrandt" <·················@gmail.com>
wrote:
> On Thu, 24 Jan 2008 23:23:35 +0100, Slobodan Blazeski
>
> <·················@gmail.com> wrote:
> >> So if you have done some GUI programming in lisp yourself, it'd be great
> >> if you would share your experience.
> > I've tried CAPI & Allegro library, but switched completely to web.
> > CAPI has a native look on windows, linux and mac. Both are easy to
> > learn. Allegro lib appears sort of CLOSish, that might be good or bad
> > depending of your point of view.
> > So If you're interested in buying commercial lisp you can walk
> > through their tutorials in few hours and get a better feeling of what
> > you're going to work with than anyone could tell you.
>
> Alright. Actually this is what I have been waiting for. Given that the
> open source libs are only suitable for small apps, still under
> development, and/or tricky to set up, I figured I would be pointed to the
> commercial libs sooner or later.
I never said anything against open source libs, they might be better,
worse or just different then commercial offerings. I just didn't tried
them.
cheers
Slobodan
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5h1kxn5x6i8pv@babyfoot>
fOn Fri, 25 Jan 2008 19:44:22 +0100, Slobodan Blazeski
<·················@gmail.com> wrote:
> On Jan 25, 7:16 pm, "Peter Hildebrandt" <·················@gmail.com>
> wrote:
>> Alright. Actually this is what I have been waiting for. Given that the
>> open source libs are only suitable for small apps, still under
>> development, and/or tricky to set up, I figured I would be pointed to
>> the
>> commercial libs sooner or later.
> I never said anything against open source libs, they might be better,
> worse or just different then commercial offerings. I just didn't tried
> them.
I just reread my post. Sorry for the confusion. I did not intend at all
to be as harsh against open source as it sounds. On the contrary, I have
been working to improve cells-gtk over the past couple weeks, and I have
published a few patches adding (IMO substantial) functionality.
My point is that the commercial implemetations provide libraries that are
ready for everyday use right now, where as the cells driven projects still
require some work.
There appears to be no free library out there that meets my needs (dreams
I should say), hence this thread tells me I gotta write my own.
Cheers,
Peter
> cheers
> Slobodan
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Peter Hildebrandt wrote:
> On Thu, 24 Jan 2008 23:23:35 +0100, Slobodan Blazeski
> <·················@gmail.com> wrote:
>
>>> > Did you googled at all , searching for common lisp GUI returned some
>>> > good results though far from complete.
>>> Did you read the rest of this thread at all? ;-)
>>
>> Actually no I was going for a drive by posting :)
>
>
> Gotcha.
>
>>> So if you have done some GUI programming in lisp yourself, it'd be great
>>> if you would share your experience.
>
>
>> I've tried CAPI & Allegro library, but switched completely to web.
>> CAPI has a native look on windows, linux and mac. Both are easy to
>> learn. Allegro lib appears sort of CLOSish, that might be good or bad
>> depending of your point of view.
>> So If you're interested in buying commercial lisp you can walk
>> through their tutorials in few hours and get a better feeling of what
>> you're going to work with than anyone could tell you.
>
>
> Alright. Actually this is what I have been waiting for. Given that
> the open source libs are only suitable for small apps, still under
> development, and/or tricky to set up, I figured I would be pointed to
> the commercial libs sooner or later. I do not have the time at this
> point to evaluate them carefully, so I hoped someone who had done so
> would tell me how useful (or not) they are.
>
> I take it from yours and John's post that both Lispworks and Allegro
> have good solutions to offer,...
Allegro's GUI does not run on the Mac AFAIK. Linux? Maybe. They ported
the IDE to Linux, anyway.
> so if I ever get tired of hacking
> cells-gtk, I know where to go.
>
> For now I'm having way too much fun with a cells driven gui :-)
If you love CAPI you can always do a Cells-CAPI. I originally cellified
the MCL GUI and played for a month with cellifying ACL's Common
Graphics, just found it easier then to roll my own widgets.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5jaspxjx6i8pv@babyfoot>
On Fri, 25 Jan 2008 22:30:45 +0100, Ken Tilton <···········@optonline.net>
wrote:
> Peter Hildebrandt wrote:
>> I take it from yours and John's post that both Lispworks and Allegro
>> have good solutions to offer,...
>
> Allegro's GUI does not run on the Mac AFAIK. Linux? Maybe. They ported
> the IDE to Linux, anyway.
Alright, so this points me more and more to CAPI as the commercial fall
back, in case cells-gtk will never work out :-)
>> so if I ever get tired of hacking cells-gtk, I know where to go.
>> For now I'm having way too much fun with a cells driven gui :-)
>
> If you love CAPI you can always do a Cells-CAPI. I originally cellified
> the MCL GUI and played for a month with cellifying ACL's Common
> Graphics, just found it easier then to roll my own widgets.
True. But once I start cellifying CAPI, will that be any different from
cellifying any other toolkit (like, say, gtk)?
Plus, I read in the CAPI doc pointed out by Edi that CAPI on linux uses
Motif [1] -- meaning it is eighties-esque [2] (would you want to sell
this?).
I think there is a point in working on cells-gtk, after all.
Peter
[1] "This means that if you display a CAPI button, a real Windows button
is created for it when running on Windows, and a real Motif button when
running on Motif, and a real Mac OS X button when running on Mac OS X"
http://www.lispworks.com/documentation/lw50/CAPUG-W/html/capiuser-w-7.htm#pgfId-884184
[2]
http://www.lispworks.com/documentation/lw445/CAPUG-U/html/capiuser-u-25.htm#pgfId-884266
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Peter Hildebrandt wrote:
> On Fri, 25 Jan 2008 22:30:45 +0100, Ken Tilton
> <···········@optonline.net> wrote:
> True. But once I start cellifying CAPI, will that be any different
> from cellifying any other toolkit (like, say, gtk)?
Just that CAPI is Lisp so things go a lot easier. And I /think/ I heard
here that the CAPI source is provided, and that would help, too.
>
> Plus, I read in the CAPI doc pointed out by Edi that CAPI on linux uses
> Motif [1] -- meaning it is eighties-esque [2] (would you want to sell
> this?).
>
> I think there is a point in working on cells-gtk, after all.
Yeah, what we really need is for Franz to shut down Common Graphics and
for Lispworks to shut down CAPI and just let Kenny do the Lisp GUIs.
They could save a ton on development and support (even after what they
would have to pay me <g>).
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
In article <·························@cv.net>,
Ken Tilton <···········@optonline.net> wrote:
> Peter Hildebrandt wrote:
> > On Fri, 25 Jan 2008 22:30:45 +0100, Ken Tilton
> > <···········@optonline.net> wrote:
>
> > True. But once I start cellifying CAPI, will that be any different
> > from cellifying any other toolkit (like, say, gtk)?
>
> Just that CAPI is Lisp so things go a lot easier. And I /think/ I heard
> here that the CAPI source is provided, and that would help, too.
CAPI source is NOT provided. Unfortunately.
>
> >
> > Plus, I read in the CAPI doc pointed out by Edi that CAPI on linux uses
> > Motif [1] -- meaning it is eighties-esque [2] (would you want to sell
> > this?).
> >
> > I think there is a point in working on cells-gtk, after all.
>
> Yeah, what we really need is for Franz to shut down Common Graphics and
> for Lispworks to shut down CAPI and just let Kenny do the Lisp GUIs.
> They could save a ton on development and support (even after what they
> would have to pay me <g>).
There are already an infinite number of parallel universes
where this is true.
>
> kt
On Jan 26, 12:13 pm, "Peter Hildebrandt" <·················@gmail.com>
wrote:
> On Fri, 25 Jan 2008 22:30:45 +0100, Ken Tilton <···········@optonline.net>
> wrote:
>
> > Peter Hildebrandt wrote:
> >> I take it from yours and John's post that both Lispworks and Allegro
> >> have good solutions to offer,...
>
> > Allegro's GUI does not run on the Mac AFAIK. Linux? Maybe. They ported
> > the IDE to Linux, anyway.
>
> Alright, so this points me more and more to CAPI as the commercial fall
> back, in case cells-gtk will never work out :-)
[Shameless plug:]
I just wrote something about lisp hackbraries
http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-of-drive.html
>
> >> so if I ever get tired of hacking cells-gtk, I know where to go.
> >> For now I'm having way too much fun with a cells driven gui :-)
>
> > If you love CAPI you can always do a Cells-CAPI. I originally cellified
> > the MCL GUI and played for a month with cellifying ACL's Common
> > Graphics, just found it easier then to roll my own widgets.
>
> True. But once I start cellifying CAPI, will that be any different from
> cellifying any other toolkit (like, say, gtk)?
>
> Plus, I read in the CAPI doc pointed out by Edi that CAPI on linux uses
> Motif [1] -- meaning it is eighties-esque [2] (would you want to sell
> this?).
You plan to sell desktop app that works on linux. Hmm..
cheers
Slobodan
http://tourdelisp.blogspot.com
>
> I think there is a point in working on cells-gtk, after all.
>
> Peter
>
> [1] "This means that if you display a CAPI button, a real Windows button
> is created for it when running on Windows, and a real Motif button when
> running on Motif, and a real Mac OS X button when running on Mac OS X"http://www.lispworks.com/documentation/lw50/CAPUG-W/html/capiuser-w-7...
>
> [2] http://www.lispworks.com/documentation/lw445/CAPUG-U/html/capiuser-u-...
>
> --
> Using Opera's revolutionary e-mail client:http://www.opera.com/mail/
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5jvbepvx6i8pv@babyfoot>
On Sat, 26 Jan 2008 16:24:03 +0100, Slobodan Blazeski
<·················@gmail.com> wrote:
> On Jan 26, 12:13 pm, "Peter Hildebrandt" <·················@gmail.com>
>> Plus, I read in the CAPI doc pointed out by Edi that CAPI on linux uses
>> Motif [1] -- meaning it is eighties-esque [2] (would you want to sell
>> this?).
> You plan to sell desktop app that works on linux. Hmm..
No, worse. I plan to /publish/ it and have /non-CS people/ use it.
I know ...
Peter
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Peder O. Klingenberg
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <kswspvx7yp.fsf@beto.netfonds.no>
"Peter Hildebrandt" <·················@gmail.com> writes:
> No, worse. I plan to /publish/ it and have /non-CS people/ use it.
Non-CS people generally don't use linux on the desktop, yet.
That said, we do have a fair number of users of the Linux version of
our CAPI based stock trading application (PrimeTrader,
<http://www.netfonds.no/manual_pt_eng.php>). I'm not terribly fond of
the motif look'n'feel on Linux, but it gets the job done. It's
certainly better than nothing, which is what our competitors are
offering on Linux. YMMV, of course.
...Peder...
--
Sl�v uten dop.
On Jan 27, 10:41 pm, ·····@news.klingenberg.no (Peder O. Klingenberg)
wrote:
> "Peter Hildebrandt" <·················@gmail.com> writes:
> > No, worse. I plan to /publish/ it and have /non-CS people/ use it.
>
> Non-CS people generally don't use linux on the desktop, yet.
Non-CS people generally never heard of linux.
Slobodan
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5l1tfgwx6i8pv@babyfoot>
On Sun, 27 Jan 2008 22:57:05 +0100, Slobodan Blazeski
<·················@gmail.com> wrote:
> On Jan 27, 10:41 pm, ·····@news.klingenberg.no (Peder O. Klingenberg)
> wrote:
>> "Peter Hildebrandt" <·················@gmail.com> writes:
>> > No, worse. I plan to /publish/ it and have /non-CS people/ use it.
>>
>> Non-CS people generally don't use linux on the desktop, yet.
> Non-CS people generally never heard of linux.
Actually none of the non-CS people in my group used anything else but
linux.
The times they are a'changing ...
Cheers,
Peter
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
P� Thu, 24 Jan 2008 19:34:56 +0100, skrev Peter Hildebrandt
<·················@gmail.com>:
>
> So if you have done some GUI programming in lisp yourself, it'd be great
> if you would share your experience.
>
> Peter
>
Well the only one of the above I have used is CAPI. Of the advantages is
that has decent documentation.
lisp-hug is a active newsletter that can give help on difficult issues.
And of course the same source runs on Windows various Unix/Linux's and
Mac's.
It is simple enough to use if you know windows programming. It can be a
bit limiting at times and requires a bit of hackery to do more complicated
layout issues.
Hello World in CAPI under LispWorks IDE. At the REPL type:
(capi:display-message "Hello World!")
Doesn't get any simpler than that...
Anyhow you can develop dialogs and windows interactively and independently
which is neat.
Also you can add functionality to the LispWorks Interface at runtime.
I should add that my experience is fairly limited. A few demo's and a
couple of small applications.
I mostly work with Hunchentoot with web interfaces.
--------------
John Thingstad
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5h1dukqx6i8pv@babyfoot>
On Thu, 24 Jan 2008 22:48:16 +0100, John Thingstad <·······@online.no>
wrote:
> På Thu, 24 Jan 2008 19:34:56 +0100, skrev Peter Hildebrandt
> <·················@gmail.com>:
>> So if you have done some GUI programming in lisp yourself, it'd be
>> great if you would share your experience.
>
> Well the only one of the above I have used is CAPI. Of the advantages is
> that has decent documentation.
> lisp-hug is a active newsletter that can give help on difficult issues.
> And of course the same source runs on Windows various Unix/Linux's and
> Mac's.
That sounds good. Expecially the documentation is a big shortcoming of
the open source projects.
> It is simple enough to use if you know windows programming. It can be a
> bit limiting at times and requires a bit of hackery to do more
> complicated layout issues.
OTOH capi is completely written in lisp, I assume? This would make
extensions a lot easier than in a tk/gtk/... wrapper.
> Hello World in CAPI under LispWorks IDE. At the REPL type:
> (capi:display-message "Hello World!")
>
> Doesn't get any simpler than that...
cells-gtk saves you three letters ;-)
(cgtk:show-message "Hello World!")
> Anyhow you can develop dialogs and windows interactively and
> independently which is neat.
That is nice functonality indeed.
If I were to write a conclusion to this thread it'd be along these lines:
The commercial packages have quite a bit to offer compared to open source
libraries. Major features include
. good documentation
. written in lisp
. native looks
. stability
The major drawback for me is that it requires everyone who works on the
project to have access to the specific lisp implementation.
With clg/ltk/celtk/cells-gtk/cello there are promising open source
projects. If you like cells, there are cells-gtk and celtk (which looks
good now thanks to tcl8.5), otherwise clg provides the most comprehensive
bindings. What we are all waiting for is cello, which will finally
provide us with a 100% cells gui.
My personal conclusion is that work on cells-gtk (or other open source
lisp gui toolkits) is not pointless, since there seem to be no better free
alternatives out there.
Thanks everyone for contributing,
Peter
> Also you can add functionality to the LispWorks Interface at runtime.
>
> I should add that my experience is fairly limited. A few demo's and a
> couple of small applications.
> I mostly work with Hunchentoot with web interfaces.
>
>
> --------------
> John Thingstad
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Edi Weitz
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <uodb9ratr.fsf@agharta.de>
On Fri, 25 Jan 2008 19:52:32 +0100, "Peter Hildebrandt" <·················@gmail.com> wrote:
> OTOH capi is completely written in lisp, I assume?
Yes. Except that it has to call into the underlying windowing system
at some point.
This short introduction gives a good overview:
http://www.lispworks.com/documentation/lw50/CAPUG-W/html/capiuser-w-4.htm
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5jadjapx6i8pv@babyfoot>
On Fri, 25 Jan 2008 19:58:56 +0100, Edi Weitz <········@agharta.de> wrote:
> On Fri, 25 Jan 2008 19:52:32 +0100, "Peter Hildebrandt"
> <·················@gmail.com> wrote:
>
>> OTOH capi is completely written in lisp, I assume?
>
> Yes. Except that it has to call into the underlying windowing system
> at some point.
>
> This short introduction gives a good overview:
>
> http://www.lispworks.com/documentation/lw50/CAPUG-W/html/capiuser-w-4.htm
Thanks for the pointer.
Peter
>
> Edi.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Peter Hildebrandt escribió:
>
> So far I have been using cells-gtk (and put together two patches), but I
> wonder whether I should rather invest time and effort into a different
> project. I believe there must be other people out there who need a
> lisp-like, dynamic, interactive, yet modern/native-looking GUI.
>
Did you try clg? It's a "closified" binding to gtk, and it's being
actively maintained.
http://sourceforge.net/projects/clg
Leandro
From: Joost Diepenmaat
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <87fxxiy865.fsf@zeekat.nl>
Leandro Rios <··················@gmail.com> writes:
> Peter Hildebrandt escribió:
>
>>
>> So far I have been using cells-gtk (and put together two patches),
>> but I wonder whether I should rather invest time and effort into a
>> different project. I believe there must be other people out there
>> who need a lisp-like, dynamic, interactive, yet
>> modern/native-looking GUI.
>>
>
> Did you try clg? It's a "closified" binding to gtk, and it's being
> actively maintained.
>
> http://sourceforge.net/projects/clg
>
> Leandro
I'm using clg for a project I've just started. It's fairly intuitive
when you've got the gtk documentation in front of you and it supports
cairo, which is really very nice if you want to do your own drawing /
widgets.
On the other hand, cells-gtk seems to be better at unifying callbacks /
observer patterns from the GTK to your own model. I'm tempted to try it,
even though it looks like I'd have to figure out how it actually works
by experimenting, since the documentation seems to be very sparse.
Joost.
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t4awnrppx6i8pv@babyfoot>
On Mon, 31 Dec 2007 20:29:38 +0100, Joost Diepenmaat <·····@zeekat.nl>
wrote:
> Leandro Rios <··················@gmail.com> writes:
> I'm using clg for a project I've just started. It's fairly intuitive
> when you've got the gtk documentation in front of you and it supports
> cairo, which is really very nice if you want to do your own drawing /
> widgets.
The core point here is "when you've got the gtk documentation": That is
exactly what I'm trying to avoid. I feel the gtk interface is quite low
level, you need quite a bit of boilerplate for pretty much everything.
And from what I can tell from the examples, clg does not really change
that.
If you don't mind writing code that looks like a gtk application, this
might be fine. However, I'd prefer a higher level of abstraction. To me
the UI is not in the center of the application, but rather a component
that somehow hooks up to my program and provides access to its functions
and data structures (a graphic repl, if you will).
> On the other hand, cells-gtk seems to be better at unifying callbacks /
> observer patterns from the GTK to your own model. I'm tempted to try it,
> even though it looks like I'd have to figure out how it actually works
> by experimenting, since the documentation seems to be very sparse.
There is a sample app, test-gtk (just like in clg), that demonstrates the
use of most widgets. Once you have understood cells, the code in test-gtk
is quite intuitive.
Given that there seems be a void here, I might get around to writing a
little tutorial for cells-gtk one of these days (I would not hold my
breath, though).
Peter
>
> Joost.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Peter Hildebrandt" <·················@gmail.com> writes:
>
> The core point here is "when you've got the gtk documentation": That is
> exactly what I'm trying to avoid. I feel the gtk interface is quite low
> level, you need quite a bit of boilerplate for pretty much everything.
Fortunately, you're using Common Lisp, and hence abstracting away
boilerplate is easier than in other languages. In my Tasting Notes
<http://octpodial-chrome.com/tasting-notes/> I've abstracted away
displaying a web page to a single macro which hides all the HTML setup
and templating; I've hidden all the dirty work of displaying a create or
update form and just specify what the form should look like.
Doing the same with gtk+ seems reasonable to me...
--
Robert Uhl <http://public.xdi.org/=ruhl>
To make laws that man cannot, and will not obey,
serves to bring all law into contempt. --E.C. Stanton
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| boilerplate is easier than in other languages. In my Tasting Notes
| <http://octpodial-chrome.com/tasting-notes/> I've abstracted away
| displaying a web page to a single macro which hides all the HTML setup...
+---------------
<http://octopodial-chrome.com/tasting-notes/> works better. ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
>
> +---------------
> | boilerplate is easier than in other languages. In my Tasting Notes
> | <http://octpodial-chrome.com/tasting-notes/> I've abstracted away
> | displaying a web page to a single macro which hides all the HTML setup...
> +---------------
>
> <http://octopodial-chrome.com/tasting-notes/> works better. ;-}
Thanks. Sorry 'bout that.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The only customer focus I'm interested in involves a table, some rope,
a sunny day, and a Really Big magnifying glass. --Roger Burton West
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t4c1rtiux6i8pv@babyfoot>
On Wed, 02 Jan 2008 19:33:14 +0100, Robert Uhl <·········@NOSPAMgmail.com>
wrote:
> "Peter Hildebrandt" <·················@gmail.com> writes:
>>
>> The core point here is "when you've got the gtk documentation": That is
>> exactly what I'm trying to avoid. I feel the gtk interface is quite low
>> level, you need quite a bit of boilerplate for pretty much everything.
>
> Fortunately, you're using Common Lisp, and hence abstracting away
> boilerplate is easier than in other languages.
Robert,
I believe this is what this whole thread is about: /How/ to abstract away
the boilerplate, that is to say, what is The Right Way to do it. In some
form or another most GUI wrappers help you get rid of Cish boilerplate,
but there are different ways to do it.
I'd sum it up somewhat along these lines:
- GTK is object oriented (which many believe is the natural representation
of GUIs)
- the C API to GTK is procedural/imperative (that is, it maps OO onto
seperate function calls and lots of pointers)
- clg provides access to the C API through a clos interface, i.e. makes it
OO again
- cells-gtk/celtk go one step further and introduce a new paradigm -- GUI
programming becomes declarative (that is, we do not only have objects, but
we declare dependencies between them and cells sorts out the propagation
of state for us)
The latter appears to be fairly new (and rarely used), but looks very
promimsing to me. Hence my point in this thread was to explore what
others think (and do).
Peter
> In my Tasting Notes
> <http://octpodial-chrome.com/tasting-notes/> I've abstracted away
> displaying a web page to a single macro which hides all the HTML setup
> and templating; I've hidden all the dirty work of displaying a create or
> update form and just specify what the form should look like.
>
> Doing the same with gtk+ seems reasonable to me...
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Peter Hildebrandt" <·················@gmail.com> writes:
>
>>> The core point here is "when you've got the gtk documentation": That
>>> is exactly what I'm trying to avoid. I feel the gtk interface is
>>> quite low level, you need quite a bit of boilerplate for pretty much
>>> everything.
>>
>> Fortunately, you're using Common Lisp, and hence abstracting away
>> boilerplate is easier than in other languages.
>
> I believe this is what this whole thread is about: /How/ to abstract
> away the boilerplate, that is to say, what is The Right Way to do it.
I don't know that there is one Right Way to do it, really. The
abstractions which make sense for a basic CRUD app are probably not
those which make sense for a financial-position tracker.
> - GTK is object oriented (which many believe is the natural
> representation of GUIs)
> - the C API to GTK is procedural/imperative (that is, it maps OO onto
> seperate function calls and lots of pointers)
> - clg provides access to the C API through a clos interface, i.e. makes
> it OO again
> - cells-gtk/celtk go one step further and introduce a new paradigm --
> GUI programming becomes declarative (that is, we do not only have
> objects, but we declare dependencies between them and cells sorts out
> the propagation of state for us)
That is certainly one approach. I wonder if simply using clg on its own
might reveal certain use patterns, which could then be abstracted away
into a declarative form (perhaps something like DEFINE-WINDOW); I know
that's been my experience with Hunchentoot so far, although obviously a
web page is different from a GUI window (for one thing, HTML is already
declarative...).
I used to use gtk+ in C and Python, and I recall that there was a _lot_
of repetition which Lisp could abstract away pretty easily.
There's always glade as well--you put together the GUI in glade, then
create it and define the proper signals in your code.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Ah well, back to the cutting edge on the coal-face of e-commerce.
--Charlie Stross
From: Joost Diepenmaat
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <87zlvoxrwv.fsf@zeekat.nl>
"Peter Hildebrandt" <·················@gmail.com> writes:
> On Mon, 31 Dec 2007 20:29:38 +0100, Joost Diepenmaat <·····@zeekat.nl>
> wrote:
>
>> Leandro Rios <··················@gmail.com> writes:
>> I'm using clg for a project I've just started. It's fairly intuitive
>> when you've got the gtk documentation in front of you and it supports
>> cairo, which is really very nice if you want to do your own drawing /
>> widgets.
>
> The core point here is "when you've got the gtk documentation": That
> is exactly what I'm trying to avoid. I feel the gtk interface is
> quite low level, you need quite a bit of boilerplate for pretty much
> everything. And from what I can tell from the examples, clg does not
> really change that.
Well, apart from the cells stuff, cells-gtk doesn't look *that* much
different from clg to me. As I said I haven't really tried cells or
cells-gtk so it may work out that "the cells stuff" is in fact a huge
improvement.
> If you don't mind writing code that looks like a gtk application, this
> might be fine. However, I'd prefer a higher level of abstraction. To
> me the UI is not in the center of the application, but rather a
> component that somehow hooks up to my program and provides access to
> its functions and data structures (a graphic repl, if you will).
Actually I really hate writing GUI code. There's /always/ too much of
it.
>> On the other hand, cells-gtk seems to be better at unifying callbacks /
>> observer patterns from the GTK to your own model. I'm tempted to try it,
>> even though it looks like I'd have to figure out how it actually works
>> by experimenting, since the documentation seems to be very sparse.
>
> There is a sample app, test-gtk (just like in clg), that demonstrates
> the use of most widgets. Once you have understood cells, the code in
> test-gtk is quite intuitive.
I think that is the problem, for me at least. Oh well. Guess I'll just
have try to use use cells, since that seems to be the only way to learn
it. I suspect the last month or so of messing with Lisp should give me a
better shot at understanding the thing :-)
> Given that there seems be a void here, I might get around to writing a
> little tutorial for cells-gtk one of these days (I would not hold my
> breath, though).
If you ever get around doing that, I would really like a short
side-by-side example of the improvement/differences of cells-gtk vs a more
straightforward gtk port like clg.
Cheers,
Joost.
Joost Diepenmaat wrote:
> "Peter Hildebrandt" <·················@gmail.com> writes:
>
>
>>On Mon, 31 Dec 2007 20:29:38 +0100, Joost Diepenmaat <·····@zeekat.nl>
>>wrote:
>>
>>
>>>Leandro Rios <··················@gmail.com> writes:
>>>I'm using clg for a project I've just started. It's fairly intuitive
>>>when you've got the gtk documentation in front of you and it supports
>>>cairo, which is really very nice if you want to do your own drawing /
>>>widgets.
>>
>>The core point here is "when you've got the gtk documentation": That
>>is exactly what I'm trying to avoid. I feel the gtk interface is
>>quite low level, you need quite a bit of boilerplate for pretty much
>>everything. And from what I can tell from the examples, clg does not
>>really change that.
>
>
> Well, apart from the cells stuff, cells-gtk doesn't look *that* much
> different from clg to me. As I said I haven't really tried cells or
> cells-gtk so it may work out that "the cells stuff" is in fact a huge
> improvement.
Talk about the blind leading the blind, I know less than nothing about
clg. But both Celtk and Cells-GTk give you CLOS wrappers for GTk
classes, and these wrappers magically talk to the C side of things
hiding a lot of boilerplate, including almost all the FFI stuff. Mind
you LTk does the same in re hiding the FFI/pipe traffic, but Cells is
keeping GUI elements self-consistent in a more general sense than Tk
itself already does (they called the company ActiveState for a reason, tho).
>
>
>>If you don't mind writing code that looks like a gtk application, this
>>might be fine. However, I'd prefer a higher level of abstraction. To
>>me the UI is not in the center of the application, but rather a
>>component that somehow hooks up to my program and provides access to
>>its functions and data structures (a graphic repl, if you will).
>
>
> Actually I really hate writing GUI code. There's /always/ too much of
> it.
My arch-nemesis The Evil Dr. Weitz will be along shortly to accuse me of
froggery, but GUIs really are a lot of fun with Cells (or any such
dataflow hack). Layout is as automatic as you want it to be or not, and
widget interdependence works so easily one ends up making richer GUIs
just because one can.
>
>
>>>On the other hand, cells-gtk seems to be better at unifying callbacks /
>>>observer patterns from the GTK to your own model. I'm tempted to try it,
>>>even though it looks like I'd have to figure out how it actually works
>>>by experimenting, since the documentation seems to be very sparse.
>>
>>There is a sample app, test-gtk (just like in clg), that demonstrates
>>the use of most widgets. Once you have understood cells, the code in
>>test-gtk is quite intuitive.
>
>
> I think that is the problem, for me at least. Oh well. Guess I'll just
> have try to use use cells, since that seems to be the only way to learn
> it. I suspect the last month or so of messing with Lisp should give me a
> better shot at understanding the thing :-)
I am confused. This does not help?:
http://common-lisp.net/project/cells-gtk/cgtk-primer.html
Add that to the huge suite of working examples (Vasily really outdid
himself on the examples) and the doc in Cells itself, and I think the
burden is on users to explain what more can be added. Of course then I
will just tell them the open source fairy has left the building so they
should contribute the doc themselves. :)
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t4a485lmx6i8pv@babyfoot>
On Wed, 02 Jan 2008 15:25:17 +0100, Ken Tilton <···········@optonline.net>
wrote:
> I am confused. This does not help?:
>
> http://common-lisp.net/project/cells-gtk/cgtk-primer.html
Actually, I have to admit, when I started working with cells-gtk, it
hardly helped. I could have used something more direct, like, lets make
an app, put a button in it, and add a callback. Once I had gotton that
far, reading the test-gtk examples was the perfect tutorial.
> Add that to the huge suite of working examples (Vasily really outdid
> himself on the examples) and the doc in Cells itself, and I think the
> burden is on users to explain what more can be added.
Indeed. I'd be happy to provide more doc on cells-gtk if anyone is
interested.
Peter.
> Of course then I will just tell them the open source fairy has left the
> building so they should contribute the doc themselves. :)
> kt
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Joost Diepenmaat
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <87y7b846gg.fsf@zeekat.nl>
Ken Tilton <···········@optonline.net> writes:
> My arch-nemesis The Evil Dr. Weitz will be along shortly to accuse me
> of froggery, but GUIs really are a lot of fun with Cells (or any such
> dataflow hack). Layout is as automatic as you want it to be or not,
> and widget interdependence works so easily one ends up making richer
> GUIs just because one can.
Your continued claims in this newsgroup are part of the reason I have
this little nagging voice in my head telling me I should give this
cells-gtk thing a shot. So well done :-)
> I am confused. This does not help?:
>
> http://common-lisp.net/project/cells-gtk/cgtk-primer.html
It did/does help, and I think I've got at least a general understanding of
what cells is supposed to do, but it did take me a few rounds of finding
and reading the different cells / cells-gtk articles lying around on the
web. Part of the problem is also my limited Lisp experience, I'm sure.
> Add that to the huge suite of working examples (Vasily really outdid
> himself on the examples) and the doc in Cells itself, and I think the
> burden is on users to explain what more can be added. Of course then I
> will just tell them the open source fairy has left the building so
> they should contribute the doc themselves. :)
The examples look great, but I still have some difficulties in getting
my mind wrapped around the whole thing. Mainly as in "now how do I use
all of this effectively / will this really work for my app". I think
I'll just have to go and really give it a good try and hope that
somewhere along the way it'll click. :-)
Joost.
On Jan 2, 3:01 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
> The examples look great, but I still have some difficulties in getting
> my mind wrapped around the whole thing. Mainly as in "now how do I use
> all of this effectively / will this really work for my app". I think
> I'll just have to go and really give it a good try and hope that
> somewhere along the way it'll click. :-)
When I first encountered cells and its family of applications I was a
bit
overwhelmed too but I'm also still a List newbie. I went and got a
better
grasp of CLOS itself and then tried again. It also helps to be
proficient
with your development environment too (whether that is SLIME, Allegro
or
whatever).
--
Andy
Andy Chambers wrote:
> On Jan 2, 3:01 pm, Joost Diepenmaat <·····@zeekat.nl> wrote:
>
>
>>The examples look great, but I still have some difficulties in getting
>>my mind wrapped around the whole thing. Mainly as in "now how do I use
>>all of this effectively / will this really work for my app". I think
>>I'll just have to go and really give it a good try and hope that
>>somewhere along the way it'll click. :-)
>
>
> When I first encountered cells and its family of applications I was a
> bit
> overwhelmed too but I'm also still a List newbie. I went and got a
> better
> grasp of CLOS itself and then tried again. It also helps to be
> proficient
> with your development environment too (whether that is SLIME, Allegro
> or
> whatever).
So does it make sense now? What was the hard part? I have been asked to
cover Cells in the Kennynote Address to ECLM 2008, and I really do not
understand what is so hard to understand about Cells, other than the
fact that it is possible at all to program that way. But Garnet's KR
(same thing, for all intents and porpoises) preceded Cells by a decade
or two and there is all that other prior and concurrent art documented
in cells-manifesto.txt and in the end, hey, it is just VisiCalc for CLOS
slots (and really any program state) so we now have a stand-off: no one
understands Cells, I do not understand what there is not to understand.
Help me help you help me help you!
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5fs2cqnx6i8pv@babyfoot>
On Tue, 22 Jan 2008 05:40:53 +0100, Ken Tilton <···········@optonline.net>
wrote:
> Help me help you help me help you!
I'll try and contribute my 2 cents. I'm somewhat new to the matter, so I
hope my experience is "fresh" enough to help. I started programming lisp
in May 2007, spent two weeks reading the first chapters of PCL, stumbled
across cells on c.l.l pretty much right away, found cells-gtk soon after,
and by now my current project relies heavily on cells. I haven't
encountered a more convenient way to do GUI stuff than with cells(-gtk).
> So does it make sense now? What was the hard part?
It makes perfect sense to me now, at least for the easy cases. (I haven't
felt the need to deal with special cells types or synapses).
The hard part for me was to fully understand that cells is /active/ state
propagation, whereas methods provide /passive/ propagation (I have always
been a fan of keeping state in as few variables as possible. Without
cells, I used plenty of methods to compute the depended part of state when
needed). Now I look at methods as a kind of "pull" mechanism whereas
cells is a "push" mechanism to propagate state change.
Once I got this into my head, I had to start figuring out which part of my
application should use which mechanism. Some stuff should be actively
pushed and propagated, while other things can be queryed on demand.
What I still have not totally figured out is how to properly get rid of
unused objects so that they are properly GC'd. I understand that cells
3.0 (or whatever you call it, the "defmd" syntax) deals better with this
than cells 2.0 (the one that comes with cells-gtk,
"defmodel"/"def-c-output" syntax). Since cells-gtk requires the older,
I'm stuck with that though.
> I have been asked to cover Cells in the Kennynote Address to ECLM 2008,
> and I really do not understand what is so hard to understand about
> Cells, other than the fact that it is possible at all to program that
> way.
Maybe that's the major problem here. So far I have not done anything with
cells (or with lisp, for that matter), that I could not have done with
java or C++. Obviously it was a lot easier to do in lisp (and again a lot
more convenient with cells), and it was more fun, too.
OTOH, I'm not a professional programmer. My work is for internal use or
serves as proof of concept. So, of course, my experience in coding is
limited, and thus I easily profit from more convenience. For a routined
programmer things will look differtently. The cost of thinking in a new
way might easily outweigh the gain in productivity.
Additionally, using a new technology, you don't know where the performance
traps will be. Again, for me this is irrelevant, because all I need to do
is show that things might work. A profiler might remedy the situation,
but it is still inferior to a well-trained intuition to spot problematic
passages.
> But Garnet's KR (same thing, for all intents and porpoises) preceded
> Cells by a decade or two and there is all that other prior and
> concurrent art documented in cells-manifesto.txt and in the end, hey, it
> is just VisiCalc for CLOS slots (and really any program state) so we now
> have a stand-off: no one understands Cells, I do not understand what
> there is not to understand.
Being the lead (only?) programmer on a project is the worst possible
starting point to address this problem ;-)
HTH,
Peter
>
> kt
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Peter Hildebrandt wrote:
> On Tue, 22 Jan 2008 05:40:53 +0100, Ken Tilton
> <···········@optonline.net> wrote:
>
>> Help me help you help me help you!
>
>
> I'll try and contribute my 2 cents. I'm somewhat new to the matter, so
> I hope my experience is "fresh" enough to help. I started programming
> lisp in May 2007, spent two weeks reading the first chapters of PCL,
> stumbled across cells on c.l.l pretty much right away,...
Can't imagine how.
>... found cells-gtk
> soon after, and by now my current project relies heavily on cells. I
> haven't encountered a more convenient way to do GUI stuff than with
> cells(-gtk).
>
>> So does it make sense now? What was the hard part?
>
>
> It makes perfect sense to me now, at least for the easy cases. (I
> haven't felt the need to deal with special cells types or synapses).
OK. Fair warning: I do find myself needing black-belt skills in Cells
fairly often, so don't hesitate to ask. Synapses are fun but I pretty
much never use them.
>
> The hard part for me was to fully understand that cells is /active/
> state propagation,...
OK, I had not thought of that.
>... whereas methods provide /passive/ propagation (I
> have always been a fan of keeping state in as few variables as
> possible. Without cells, I used plenty of methods to compute the
> depended part of state when needed). Now I look at methods as a kind
> of "pull" mechanism whereas cells is a "push" mechanism to propagate
> state change.
I think of it as the difference between a working model that runs by
itself and one that works only because the puppeteer/progammer makes the
model work with tediously explicit coding of the consequences of any
state change.
With Cells I simply write the formula for different bits of state and
when one domino falls the rest follow. Without Cells we have oh golly
this domino fell I have to figure out which dominos are nearby and will
get hit oh and remember to play the clattering WAV and redraw the screen
and..
Of course in neither case is the programmer still around when either
program is running, I am just describing the difference in the feel of
programming with Cells and without.
>
> Once I got this into my head, I had to start figuring out which part of
> my application should use which mechanism. Some stuff should be
> actively pushed and propagated, while other things can be queryed on
> demand.
There is a lazy option for Cells, just not sure it goes back as Cells 2.
Otherwise, I found Cells to be a slippery slope in that it draws more
and more of the application into Cells-mediated state once one uses
Cells for anything. Talk about Xah's concern with things happening
behind the scenes! That is where the action is in any constraints
application, and if one wants to hang out usefully with Cells-mediated
state one better be mediated by a Cell.
>
> What I still have not totally figured out is how to properly get rid of
> unused objects so that they are properly GC'd. I understand that cells
> 3.0 (or whatever you call it, the "defmd" syntax) deals better with
> this than cells 2.0 (the one that comes with cells-gtk,
> "defmodel"/"def-c-output" syntax). Since cells-gtk requires the older,
> I'm stuck with that though.
Hmmm, I do not think I have ever heard of this issue, or had a problem
myself with objects held overlong, in any Cells version. Fill me in.
>
>> I have been asked to cover Cells in the Kennynote Address to ECLM
>> 2008, and I really do not understand what is so hard to understand
>> about Cells, other than the fact that it is possible at all to
>> program that way.
>
>
> Maybe that's the major problem here. So far I have not done anything
> with cells (or with lisp, for that matter), that I could not have done
> with java or C++. Obviously it was a lot easier to do in lisp (and
> again a lot more convenient with cells), and it was more fun, too.
>
> OTOH, I'm not a professional programmer. My work is for internal use
> or serves as proof of concept. So, of course, my experience in coding
> is limited, and thus I easily profit from more convenience. For a
> routined programmer things will look differtently. The cost of
> thinking in a new way might easily outweigh the gain in productivity.
Oh, let's not dress up these hide-bound reactionary head-in-the-sand
Lisp yobbos as cost-rational. :) But one big thing is the other point I
made in this thread: Lispers rarely actually program in Lisp and more
rarely program GUIs. I have used Cells for lots more than GUIs, but GUIs
are the poster boy for interdependent state and random arrival of
unpredictable state (thx, users!).
Getting back to the cost of thinking in a new way, all I remember when
we hit on Cells was how much fun it was to program that way, partly
because it made everything astonishingly easier (we could not believe it
at first and kept thinking we'd run into a fatal flaw) and partly
because it /was/ different. In Blazing Saddles we learned not to shoot
Mongo, it only makes him angry. With good programmers it is OK to have
them use unfamiliar technology, the stimulus of something novel only
makes them more productive.
>
> Additionally, using a new technology, you don't know where the
> performance traps will be. Again, for me this is irrelevant, because
> all I need to do is show that things might work. A profiler might
> remedy the situation, but it is still inferior to a well-trained
> intuition to spot problematic passages.
>
>> But Garnet's KR (same thing, for all intents and porpoises) preceded
>> Cells by a decade or two and there is all that other prior and
>> concurrent art documented in cells-manifesto.txt and in the end, hey,
>> it is just VisiCalc for CLOS slots (and really any program state) so
>> we now have a stand-off: no one understands Cells, I do not
>> understand what there is not to understand.
>
>
> Being the lead (only?) programmer on a project is the worst possible
> starting point to address this problem ;-)
Yeah, I learned not to even try (listening, Dr. Tarver? Froggy?) but Edi
was crazy enough to ask me to at ECLM so I am planning on explaining it
all in five minutes and then making fun of them for last forty.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5gb7sfyx6i8pv@babyfoot>
On Thu, 24 Jan 2008 20:30:08 +0100, Ken Tilton <···········@optonline.net>
wrote:
>> chapters of PCL, stumbled across cells on c.l.l pretty much right
>> away,...
> Can't imagine how.
In case this is not ironic -- I read all kinds of "I'm a noob and what
should I do?" and "Why the heck do you program in lisp despite of all
those parenthesis?" threads. Someone pointed out cells in one of the
latter. I became curious. And here I am now, hacking cellsy widgets for
cells-gtk.
>>> So does it make sense now? What was the hard part?
>> It makes perfect sense to me now, at least for the easy cases. (I
>> haven't felt the need to deal with special cells types or synapses).
>
> OK. Fair warning: I do find myself needing black-belt skills in Cells
> fairly often, so don't hesitate to ask. Synapses are fun but I pretty
> much never use them.
Thanks for the invitation. I'll start spamming cells-devel soon.
>> The hard part for me was to fully understand that cells is /active/
>> state propagation,...
>
> OK, I had not thought of that.
I think we mean the same thing. Cells means you poke the model somewhere
and then the effects wander magically to where they are needed.
>> ... whereas methods provide /passive/ propagation (I have always been
>> a fan of keeping state in as few variables as possible. Without
>> cells, I used plenty of methods to compute the depended part of state
>> when needed). Now I look at methods as a kind of "pull" mechanism
>> whereas cells is a "push" mechanism to propagate state change.
>
> I think of it as the difference between a working model that runs by
> itself and one that works only because the puppeteer/progammer makes the
> model work with tediously explicit coding of the consequences of any
> state change.
Here we had different ideas of a non-cell program. You were thinking
about coding the consequences of every change. I was thinking of
computing the dependent parts on the state on the fly every time they are
needed. It is like every limb of the puppet having to constantly ask
where it should be and what it should do.
> With Cells I simply write the formula for different bits of state and
> when one domino falls the rest follow. Without Cells we have oh golly
> this domino fell I have to figure out which dominos are nearby and will
> get hit oh and remember to play the clattering WAV and redraw the screen
> and..
Very nice picture :-)
>> Some stuff should be actively pushed and propagated, while other
>> things can be queryed on demand.
> There is a lazy option for Cells, just not sure it goes back as Cells 2.
>
> Otherwise, I found Cells to be a slippery slope in that it draws more
> and more of the application into Cells-mediated state once one uses
> Cells for anything.
That's what I had in mind when I wrote this. I find myself doing pretty
much everything with cells, and I wonder whether some of those things
should better be done without cells.
Take ODE for example: cl-ode maps the ODE api nicely to lisp. However, I
would prefer a lisp-like wrapper, so that I could instantiate objects and
call methods instead of writing hundreds of procedure calls. I thought of
using cells and make it models, but I could not figure out the Right Way
to do it.
I imagined something like (defmd box () ((x :accessor x ...))), but could
not see how to update x properly. I ended up setf'ing all coordinate
slots of all objects after every ODE iteration. But then, what if I want
to move an object? The user setf's the coordinate, and I need an observer
propagating the setf to ODE. But then, during my update I would want to
deactivate the propagation ... arrrgh, I thought, removed the coordinate
slots, and wrote query methods directly calling ode and setf methods
writing to ode.
This way I removed the duplication of state -- however changes in ODE are
not propagated anymore. I have to make sure I call the methods reading
from ODE every time I want to know where an object is.
If you have an idea how to wrap cells around this one, I'd be most
grateful.
>> What I still have not totally figured out is how to properly get rid
>> of unused objects so that they are properly GC'd. I understand that
>> cells 3.0 (or whatever you call it, the "defmd" syntax) deals better
>> with this than cells 2.0 (the one that comes with cells-gtk,
>> "defmodel"/"def-c-output" syntax). Since cells-gtk requires the
>> older, I'm stuck with that though.
>
> Hmmm, I do not think I have ever heard of this issue, or had a problem
> myself with objects held overlong, in any Cells version. Fill me in.
It's a long story, and it is not exactly cells' fault. There is an issue
with the way cells-gtk keeps track of widgets: every widget is stored in
a hash table. However, not all widgets are removed properly upon
destruction. gtk is supposed to send a message, but apparently fails to
do so. So I wrote some code into the not-to-be methods to remove the
object from the hash-table. not-to-be methods are called automatically
for all kids, so this works fine.
However, not-to-be is not called for objects that were held in other cell
slots. Hence I started to call it manually -- and kept stumbling accross
"assertion failed: (not md-state :eternal-rest)" errors. So I figured
somehow cells tries to access this object even though it should be
obsolete at the point I call not-to-be.
I found a work around so I never spent the time to investigate properly
what is going on there.
>> For a routined programmer things will look differtently. The cost of
>> thinking in a new way might easily outweigh the gain in productivity.
>
> Oh, let's not dress up these hide-bound reactionary head-in-the-sand
> Lisp yobbos as cost-rational. :)
Hey, I am just trying to find some explanation.
Here's another one: I have not found a lot of cells code out there
(besides your examples, which are terrific), so it is hard to imagine what
real world cells code would look like (unless you go ahead and write it
yourself.
Maybe you have to get Peter Seibel to write Practical Cells Code or Paul
Graham to publish On Cells.
> But one big thing is the other point I made in this thread: Lispers
> rarely actually program in Lisp and more rarely program GUIs. I have
> used Cells for lots more than GUIs, but GUIs are the poster boy for
> interdependent state and random arrival of unpredictable state (thx,
> users!).
Or, there are quite a few lisp programmers who never read c.l.l -- and
thus never even hear of cells.
I believe the reason GUI programming does not have a stronger impact is
that we lack an all-purpose GUI library based on cells. celtk, cells-gtk,
and cello are all great libraries, but I can see how someone who has not
experienced the "cells bump" yet is scared away by the look of tcl/tk, the
lacking widgets in cells-gtk, or the installation woes and the even
smaller number of widgets in cello. I should stop reading usenet and get
back to work.
> Getting back to the cost of thinking in a new way, all I remember when
> we hit on Cells was how much fun it was to program that way, partly
> because it made everything astonishingly easier (we could not believe it
> at first and kept thinking we'd run into a fatal flaw) and partly
> because it /was/ different. In Blazing Saddles we learned not to shoot
> Mongo, it only makes him angry. With good programmers it is OK to have
> them use unfamiliar technology, the stimulus of something novel only
> makes them more productive.
Agreed. I am having a lot of fun over here. Too bad all those
java/c++/python people can't see us. They will never know what they're
missing out on.
>> Being the lead (only?) programmer on a project is the worst possible
>> starting point to address this problem ;-)
>
> Yeah, I learned not to even try (listening, Dr. Tarver? Froggy?) but Edi
> was crazy enough to ask me to at ECLM so I am planning on explaining it
> all in five minutes and then making fun of them for last forty.
Maybe I should join the ECLM, after all. Sounds like fun ;)
Peter
>
> kt
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Peter Hildebrandt wrote:
> On Thu, 24 Jan 2008 20:30:08 +0100, Ken Tilton
> <···········@optonline.net> wrote:
>
>>> chapters of PCL, stumbled across cells on c.l.l pretty much right
>>> away,...
>>
>> Can't imagine how.
>
>
> In case this is not ironic -- I read all kinds of "I'm a noob and what
> should I do?" and "Why the heck do you program in lisp despite of all
> those parenthesis?" threads. Someone pointed out cells in one of the
> latter.
Yeah, I was kidding, I shut down the Cells spammer a while ago. Decided
to go green on the pearls before swine.
> That's what I had in mind when I wrote this. I find myself doing
> pretty much everything with cells, and I wonder whether some of those
> things should better be done without cells.
You are doing better than I did, I went the other way and when tackling
any new big chunk of functionality found myself unconciously reverting
to setfology. Then I would get this weird painful depressinn deja vu
feeling and eventually realized, oh, right, Cells.
I always say the one thing wrong with Cells is that it is hard to be a
little bit Cells. But that just makes me want to do analogies about
being married to Anna Kournikova.
>
> Take ODE for example: cl-ode maps the ODE api nicely to lisp. However,
> I would prefer a lisp-like wrapper, so that I could instantiate objects
> and call methods instead of writing hundreds of procedure calls. I
> thought of using cells and make it models, but I could not figure out
> the Right Way to do it.
>
> I imagined something like (defmd box () ((x :accessor x ...))), but
> could not see how to update x properly. I ended up setf'ing all
> coordinate slots of all objects after every ODE iteration. But then,
> what if I want to move an object? The user setf's the coordinate, and
> I need an observer propagating the setf to ODE. But then, during my
> update I would want to deactivate the propagation ... arrrgh, I
> thought, removed the coordinate slots, and wrote query methods directly
> calling ode and setf methods writing to ode.
>
> This way I removed the duplication of state -- however changes in ODE
> are not propagated anymore. I have to make sure I call the methods
> reading from ODE every time I want to know where an object is.
>
> If you have an idea how to wrap cells around this one, I'd be most
> grateful.
Did you see my note on the ogl-node class and dsp-list slot? We can take
this to the Cells list. If cl-ode is a clean install I'll try adding it
to Cello over here so I can play along. Mastenbrook will be thrilled to
learn Cello has a new library.
>
>>> What I still have not totally figured out is how to properly get
>>> rid of unused objects so that they are properly GC'd. I understand
>>> that cells 3.0 (or whatever you call it, the "defmd" syntax) deals
>>> better with this than cells 2.0 (the one that comes with
>>> cells-gtk, "defmodel"/"def-c-output" syntax). Since cells-gtk
>>> requires the older, I'm stuck with that though.
>>
>>
>> Hmmm, I do not think I have ever heard of this issue, or had a
>> problem myself with objects held overlong, in any Cells version. Fill
>> me in.
>
>
> It's a long story, and it is not exactly cells' fault. There is an
> issue with the way cells-gtk keeps track of widgets: every widget is
> stored in a hash table. However, not all widgets are removed properly
> upon destruction. gtk is supposed to send a message, but apparently
> fails to do so.
GTk? Because some widget gets dropped? These life/death matters always
get hairy, I usually blow a day on a new toolkit sorting out all the
different ways things can appear and disappear and figuring out exactly
where to cut.
> So I wrote some code into the not-to-be methods to
> remove the object from the hash-table. not-to-be methods are called
> automatically for all kids, so this works fine.
Sure, that is the way to go. That should be in Cells-Gtk.
>
> However, not-to-be is not called for objects that were held in other
> cell slots.
You still need Cells 3.0, it offers a new "owning" slot attribute that
tells Cells to do the to-be/not-to-be thing on values.
> Hence I started to call it manually -- and kept stumbling
> accross "assertion failed: (not md-state :eternal-rest)" errors. So I
> figured somehow cells tries to access this object even though it should
> be obsolete at the point I call not-to-be.
Oh that life/death thing. It may also be a Cells2/3 thing, I do recall
tweaking something recently in this regard, just not sure of all the
deets. It sounds more like you are trying to do something with an object
which has already been flagged as dead (eternal rest). You might have to
move your code into a :before method on not-to-be instead of :after, but
don't take my word for that. Or maybe in Cells3 I improved that since it
is normal and intended for applications to be doing things with dying
instances in not-to-be.
>
> I found a work around so I never spent the time to investigate properly
> what is going on there.
>
>>> For a routined programmer things will look differtently. The cost
>>> of thinking in a new way might easily outweigh the gain in
>>> productivity.
>>
>>
>> Oh, let's not dress up these hide-bound reactionary head-in-the-sand
>> Lisp yobbos as cost-rational. :)
>
>
> Hey, I am just trying to find some explanation.
>
> Here's another one: I have not found a lot of cells code out there
> (besides your examples, which are terrific), so it is hard to imagine
> what real world cells code would look like (unless you go ahead and
> write it yourself.
Come to ECLM. :) I /think/ I could find a version of RoboCells you could
at least read, that was both real-world and non-gui.
>
> Maybe you have to get Peter Seibel to write Practical Cells Code...
You have not read cells-manifesto.txt. :) Peter did the cost-efficiency
thing and decided it was easier to reject Cells without looking than
understand it. He was not wrong!
> Paul Graham to publish On Cells.
I found where he was asking for ideas on what to put in Arc, I suggested
Cells, no luck.
> I believe the reason GUI programming does not have a stronger impact is
> that we lack an all-purpose GUI library based on cells. celtk,
> cells-gtk, and cello are all great libraries, but I can see how someone
> who has not experienced the "cells bump" yet is scared away by the look
> of tcl/tk,...
I thought we decided Tile was helping with that.
> Maybe I should join the ECLM, after all. Sounds like fun ;)
The off-site (at a publick house yet to be determined) Yobbos vs Kenny
Smackdown was going to be a highlight, but last I heard they had
chickened out and were not coming. But we'll figure out some way to have
a smackdown, you should come.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5i9stsax6i8pv@babyfoot>
On Thu, 24 Jan 2008 23:16:50 +0100, Ken Tilton <···········@optonline.net>
wrote:
> Yeah, I was kidding, I shut down the Cells spammer a while ago. Decided
> to go green on the pearls before swine.
It's a shame. Understandable, though.
>> That's what I had in mind when I wrote this. I find myself doing
>> pretty much everything with cells, and I wonder whether some of those
>> things should better be done without cells.
>
> You are doing better than I did, I went the other way and when tackling
> any new big chunk of functionality found myself unconciously reverting
> to setfology. Then I would get this weird painful depressinn deja vu
> feeling and eventually realized, oh, right, Cells.
I was lucky. A year ago I decided to take on a major project, and I was
fed up with all the languages I knew so far. Then I cut all the strings
and took up lisp and cells at the same time.
> I always say the one thing wrong with Cells is that it is hard to be a
> little bit Cells. But that just makes me want to do analogies about
> being married to Anna Kournikova.
I got to admit, I have not reached the point where coding in cells feels
like being married to Anna Kournikova. Please, tell me what I need to
do! (I'm sure others are interested, too. Wouldn't that make a great ad
campaign for cells? but I digress ...)
> Did you see my note on the ogl-node class and dsp-list slot? We can take
> this to the Cells list. If cl-ode is a clean install I'll try adding it
> to Cello over here so I can play along. Mastenbrook will be thrilled to
> learn Cello has a new library
cells-devel is the right place to discuss this. I'll respond to your mail
there in a second.
>>>> What I still have not totally figured out is how to properly get
>>>> rid of unused objects so that they are properly GC'd. I understand
>>>> that cells 3.0 (or whatever you call it, the "defmd" syntax) deals
>>>> better with this than cells 2.0 (the one that comes with
>>>> cells-gtk, "defmodel"/"def-c-output" syntax). Since cells-gtk
>>>> requires the older, I'm stuck with that though.
>> So I wrote some code into the not-to-be methods to remove the object
>> from the hash-table. not-to-be methods are called automatically for
>> all kids, so this works fine.
>
> Sure, that is the way to go. That should be in Cells-Gtk.
Well, it wasn't. Running test-gtk allocates some 330 objects, about 100
of which are not freed, when the app is closed. This did not become
apparent because programms tend to call cells-gtk-init before each run,
purging everything out there.
Once I had the threaded version up and running giving me a dynamic
environment in which I have my application window(s) open while I code,
the purge-all approach was out of question, of course. I found most of
the leaks and cut it down to about 30 leftover objects in test-gtk. For
the rest, I ran into the eternal-rest issue. I think the problem is that
cells-gtk has its own "destroy" mechanism that kind of duplicates
not-to-be, and the two don't interact well. I'm still looking into this.
> You still need Cells 3.0, it offers a new "owning" slot attribute that
> tells Cells to do the to-be/not-to-be thing on values.
As you remarked earlier on the cells-gtk list, this is a major project
since it entails porting all of cells-gtk to cells 3.0. OTOH this might
well be worthwhile. Maybe we should discuss this on the list, though.
>> Here's another one: I have not found a lot of cells code out there
>> (besides your examples, which are terrific), so it is hard to imagine
>> what real world cells code would look like (unless you go ahead and
>> write it yourself.
>
> Come to ECLM. :) I /think/ I could find a version of RoboCells you could
> at least read, that was both real-world and non-gui.
That'd be awesome.
>> Maybe you have to get Peter Seibel to write Practical Cells Code...
>
> You have not read cells-manifesto.txt. :) Peter did the cost-efficiency
> thing and decided it was easier to reject Cells without looking than
> understand it. He was not wrong!
Come to think of it, I think remembering this.
>> Paul Graham to publish On Cells.
>
> I found where he was asking for ideas on what to put in Arc, I suggested
> Cells, no luck.
Probably to closy. I assume he could do all that easily with closures.
And the names are too long ("defobserver", come on!) :)
>> I believe the reason GUI programming does not have a stronger impact
>> is that we lack an all-purpose GUI library based on cells. celtk,
>> cells-gtk, and cello are all great libraries, but I can see how
>> someone who has not experienced the "cells bump" yet is scared away by
>> the look of tcl/tk,...
>
> I thought we decided Tile was helping with that.
May take is that tcl8.5 solves that. But since only the latest debian
unstable provides that (even the oh so popular ubuntu will have to wait
till April), at this point it /still/ is an issue. And there will be some
lag time until everyone has updated to a 2008 distribution. (There appear
to be guys out there who still use a 2002 Windows XP!)
>> Maybe I should join the ECLM, after all. Sounds like fun ;)
>
> The off-site (at a publick house yet to be determined) Yobbos vs Kenny
> Smackdown was going to be a highlight, but last I heard they had
> chickened out and were not coming. But we'll figure out some way to have
> a smackdown, you should come.
Those damn yobbos ;)
Peter
>
> kt
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Peter Hildebrandt wrote:
> May take is that tcl8.5 solves that. But since only the latest debian
> unstable provides that (even the oh so popular ubuntu will have to wait
> till April), at this point it /still/ is an issue. And there will be
> some lag time until everyone has updated to a 2008 distribution.
> (There appear to be guys out there who still use a 2002 Windows XP!)
Well, installing 8.5 with the activestate installer is a matter or a
minute - so no need to wait until your distribution eventually has it
by default.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5jwbrogx6i8pv@babyfoot>
On Sat, 26 Jan 2008 15:15:08 +0100, Peter Herth <·······@t-online.de>
wrote:
> Well, installing 8.5 with the activestate installer is a matter or a
> minute - so no need to wait until your distribution eventually has it
> by default.
Thanks for pointing this out. When I checked I searched for an ubuntu
package (I know, I am spoiled), and it took me a while to find it (since
it is not yet officially supported).
I just installed the activestate distribution, and it works like a charm.
Thanks again,
Peter
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Maciej Katafiasz
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <fng57m$9u2$2@news.net.uni-c.dk>
Den Sat, 26 Jan 2008 11:51:55 +0100 skrev Peter Hildebrandt:
>>> I believe the reason GUI programming does not have a stronger impact
>>> is that we lack an all-purpose GUI library based on cells. celtk,
>>> cells-gtk, and cello are all great libraries, but I can see how
>>> someone who has not experienced the "cells bump" yet is scared away
>>> by the look of tcl/tk,...
>>
>> I thought we decided Tile was helping with that.
>
> May take is that tcl8.5 solves that.
I'd just like to point that arse-ugly looks, whilst most visible, is not
the only problem with using Tk. Things like consistency with the rest of
my desktop (which is based on GTK+), out of the box support for input
methods (I happen to need the ability to input Polish, Danish and
Japanese, with some other languages like Russian also being a concern)
etc. are at least as important as the question of whether it makes my
eyes bleed.
Cheers,
Maciej
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t5j2jeuax6i8pv@babyfoot>
On Sat, 26 Jan 2008 21:29:42 +0100, Maciej Katafiasz <········@gmail.com>
wrote:
> Den Sat, 26 Jan 2008 11:51:55 +0100 skrev Peter Hildebrandt:
>
>>>> I believe the reason GUI programming does not have a stronger impact
>>>> is that we lack an all-purpose GUI library based on cells. celtk,
>>>> cells-gtk, and cello are all great libraries, but I can see how
>>>> someone who has not experienced the "cells bump" yet is scared away
>>>> by the look of tcl/tk,...
>>>
>>> I thought we decided Tile was helping with that.
>>
>> May take is that tcl8.5 solves that.
>
> I'd just like to point that arse-ugly looks, whilst most visible, is not
> the only problem with using Tk. Things like consistency with the rest of
> my desktop (which is based on GTK+), out of the box support for input
> methods (I happen to need the ability to input Polish, Danish and
> Japanese, with some other languages like Russian also being a concern)
> etc. are at least as important as the question of whether it makes my
> eyes bleed.
I should point out that cells-gtk has issues with utf-8 as well. We have
been working on this for the last couple days, but it is not yet fixed.
AFAIK clg handles utf-8 in gtk fully transparently.
Cheers,
Peter
>
> Cheers,
> Maciej
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Edi Weitz
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <u1w90gsnv.fsf@agharta.de>
On Wed, 02 Jan 2008 09:25:17 -0500, Ken Tilton <···········@optonline.net> wrote:
> My arch-nemesis The Evil Dr. Weitz will be along shortly to accuse
> me of froggery,
Nah, never. If I dared to disagree with you once or twice in the last
days it was just because I sensed a certain softness sneaking into
your replies and I didn't want that to become a steady state in 2008.
I'll happily retreat to my cave lurking once you're fully up and
running again.
> but GUIs really are a lot of fun with Cells
Will you demo some of this in Amsterdam? I know, the talk is actually
about Triple-Cells and other things, but I'm sure lots of people
(including me) haven't seen this stuff in action yet.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Wed, 02 Jan 2008 09:25:17 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>My arch-nemesis The Evil Dr. Weitz will be along shortly to accuse
>>me of froggery,
>
>
> Nah, never. If I dared to disagree with you once or twice in the last
> days it was just because I sensed a certain softness sneaking into
> your replies and I didn't want that to become a steady state in 2008.
> I'll happily retreat to my cave lurking once you're fully up and
> running again.
>
>
>>but GUIs really are a lot of fun with Cells
>
>
> Will you demo some of this in Amsterdam?
Yes.
> I know, the talk is actually
> about Triple-Cells and other things, but I'm sure lots of people
> (including me) haven't seen this stuff in action yet.
Well it has only been twelve years since I told the Lisp community about
Cells, no reason to think it should have sunk in yet!
<sigh>
kzo
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <op.t4a4f5r0x6i8pv@babyfoot>
On Wed, 02 Jan 2008 14:45:20 +0100, Joost Diepenmaat <·····@zeekat.nl>
wrote:
> "Peter Hildebrandt" <·················@gmail.com> writes:
>> On Mon, 31 Dec 2007 20:29:38 +0100, Joost Diepenmaat <·····@zeekat.nl>
>> wrote:
>>
>>> Leandro Rios <··················@gmail.com> writes:
>>> I'm using clg for a project I've just started. It's fairly intuitive
>>> when you've got the gtk documentation in front of you and it supports
>>> cairo, which is really very nice if you want to do your own drawing /
>>> widgets.
>>
>> The core point here is "when you've got the gtk documentation": That
>> is exactly what I'm trying to avoid. I feel the gtk interface is
>> quite low level, you need quite a bit of boilerplate for pretty much
>> everything. And from what I can tell from the examples, clg does not
>> really change that.
>
> Well, apart from the cells stuff, cells-gtk doesn't look *that* much
> different from clg to me. As I said I haven't really tried cells or
> cells-gtk so it may work out that "the cells stuff" is in fact a huge
> improvement.
I guess it depends on the application. Say, you have a fairly large
network of instances, and the state of each instance depends on the
others. Then there should be some way to modify certain input parameters
on each instance by the user (and the rest should be kept consistent).
Then you can either keep track of all the rules and dependencies, and
remeber each time you modify a parameter to tranverse down the dependency
graph and propagate the changes -- or you just declare the dependencies at
instantiation time and let cells do the rest.
And while you're at it, instantiating a couple of GUI widgets that keep
track of the cells objects' is almost for free. And voila, your GUI is
always up to date.
>> If you don't mind writing code that looks like a gtk application, this
>> might be fine. However, I'd prefer a higher level of abstraction. To
>> me the UI is not in the center of the application, but rather a
>> component that somehow hooks up to my program and provides access to
>> its functions and data structures (a graphic repl, if you will).
>
> Actually I really hate writing GUI code. There's /always/ too much of
> it.
Agreed. OTOH, I believe once your algorithm reaches a certain degree of
complexity (or you're not even sure what your algorithm actually does),
visualization really helps. And if it is two way, that is you can not
only visualize, but modify stuff, it's like interactive programming taken
to the next level.
>>> On the other hand, cells-gtk seems to be better at unifying callbacks /
>>> observer patterns from the GTK to your own model. I'm tempted to try
>>> it,
>>> even though it looks like I'd have to figure out how it actually works
>>> by experimenting, since the documentation seems to be very sparse.
>>
>> There is a sample app, test-gtk (just like in clg), that demonstrates
>> the use of most widgets. Once you have understood cells, the code in
>> test-gtk is quite intuitive.
>
> I think that is the problem, for me at least. Oh well. Guess I'll just
> have try to use use cells, since that seems to be the only way to learn
> it. I suspect the last month or so of messing with Lisp should give me a
> better shot at understanding the thing :-)
Depending on what you're working on, it might well be worth it. There is
actually some documentation on cells out there (a tutorial directory in
the package and two docs, I believe. You should ask Kenny if you're
interested)
>> Given that there seems be a void here, I might get around to writing a
>> little tutorial for cells-gtk one of these days (I would not hold my
>> breath, though).
>
> If you ever get around doing that, I would really like a short
> side-by-side example of the improvement/differences of cells-gtk vs a
> more
> straightforward gtk port like clg.
I'm no expert on the "straightforward" side of things. Additionally, I'm
afraid I'd chose an example that is clearly biased towards an elegant
cells solution.
Therefore I suggest the following:
You post an example problem along with the clg code to do it, and I will
reply with a cells-gtk version. I'll be happy to explain what is
easy/hard to do, and what extra functionality could be added easily.
Other contributors would welcome (I'd like to see the celtk, LTK,
lambda-gtk or even McCLIM solution).
How about that?
Peter
> Cheers,
>
> Joost.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Joost Diepenmaat
Subject: Re: How do lispers do their GUI programming anyway?
Date:
Message-ID: <87tzlw43lc.fsf@zeekat.nl>
"Peter Hildebrandt" <·················@gmail.com> writes:
> On Wed, 02 Jan 2008 14:45:20 +0100, Joost Diepenmaat <·····@zeekat.nl>
> wrote:
>> "Peter Hildebrandt" <·················@gmail.com> writes:
>>> On Mon, 31 Dec 2007 20:29:38 +0100, Joost Diepenmaat <·····@zeekat.nl>
>>> wrote:
>>>
>>>> Leandro Rios <··················@gmail.com> writes:
>>>> I'm using clg for a project I've just started. It's fairly intuitive
>>>> when you've got the gtk documentation in front of you and it supports
>>>> cairo, which is really very nice if you want to do your own drawing /
>>>> widgets.
>>>
>>> The core point here is "when you've got the gtk documentation": That
>>> is exactly what I'm trying to avoid. I feel the gtk interface is
>>> quite low level, you need quite a bit of boilerplate for pretty much
>>> everything. And from what I can tell from the examples, clg does not
>>> really change that.
>>
>> Well, apart from the cells stuff, cells-gtk doesn't look *that* much
>> different from clg to me. As I said I haven't really tried cells or
>> cells-gtk so it may work out that "the cells stuff" is in fact a huge
>> improvement.
>
> I guess it depends on the application. Say, you have a fairly large
> network of instances, and the state of each instance depends on the
> others. Then there should be some way to modify certain input
> parameters on each instance by the user (and the rest should be kept
> consistent).
Actually the program I'm working on must allow the user to build his own
network of instances and dependencies. The basic idea is that of a
modular synthesizer: you get a bunch of functions which instantiate
"modules" - oscillators, filters, audio outputs etc which all have zero
or more input and output ports that can be connected. Simple example:
Frequency in Hz -> [ Osc ] - audio -> [ mixer ] - right -> [ audio out ]
gain -> [ ] - left -> [ ]
panning -> [ ]
So I not only need to adjust the various parameters like Frequency, Gain
and Panning, I also need to instantiate different modules and
(dis)connect them, which can add and remove parameters to adjust.
On top of that, the kind of modules you can create is partly determined at
run-time based on whatever LADSPA plugin libraries are available, so
there is no hard-coded list of modules + slots; I can't make a
defmodel for each module type; each module /instance/ should describe
itself, including what input and output parameters it has.
I am already putting observable methods and properties in all kinds of
places, and it seems to me that cells may work for this, and possibly can
make the code clearer since right now I still have to hook clg's (gtk)
signals to the properties and vice versa and the code for doing that is
not very complicated but just annoying.
> Then you can either keep track of all the rules and dependencies, and
> remeber each time you modify a parameter to tranverse down the
> dependency graph and propagate the changes -- or you just declare the
> dependencies at instantiation time and let cells do the rest.
>
> And while you're at it, instantiating a couple of GUI widgets that
> keep track of the cells objects' is almost for free. And voila, your
> GUI is always up to date.
>
>>> If you don't mind writing code that looks like a gtk application, this
>>> might be fine. However, I'd prefer a higher level of abstraction. To
>>> me the UI is not in the center of the application, but rather a
>>> component that somehow hooks up to my program and provides access to
>>> its functions and data structures (a graphic repl, if you will).
>>
>> Actually I really hate writing GUI code. There's /always/ too much of
>> it.
>
> Agreed. OTOH, I believe once your algorithm reaches a certain degree
> of complexity (or you're not even sure what your algorithm actually
> does), visualization really helps. And if it is two way, that is you
> can not only visualize, but modify stuff, it's like interactive
> programming taken to the next level.
That's certainly true for my program. I'm not just writing GUI code
because I'm a masochist. :-)
> I'm no expert on the "straightforward" side of things. Additionally,
> I'm afraid I'd chose an example that is clearly biased towards an
> elegant cells solution.
>
> Therefore I suggest the following:
>
> You post an example problem along with the clg code to do it, and I
> will reply with a cells-gtk version. I'll be happy to explain what is
> easy/hard to do, and what extra functionality could be added easily.
> Other contributors would welcome (I'd like to see the celtk, LTK,
> lambda-gtk or even McCLIM solution).
>
>
> How about that?
Sounds good, but it will take a while to set up the example. The code I
have right now is too large and too dependent on other stuff (and only
partly working anyway).
Joost.
From: David Golden
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <bidej.23982$j7.447021@news.indigo.ie>
Peter Hildebrandt wrote:
> a modern standard look and feel (in particular I do not enjoy the
> hard edged appearance of tk on linux (I know that one can use skins
> for tk, but I don't want my users to have to deal with this)
>
Tk 8.5.0 is a large improvement in looks on linux.
All themed (ttk, formerly "tile") widgets and the updated tk widgets
now use antialiased fonts - which makes everything look better.
"Out of box", it comes with 4 themes for themed (Ttk) widgets and
updated+improved (but not actually themed, just the old color scheme
variations) Tk widgets. The look closest to the old Tk linux look
isn't the updated Tk widgets, it's the Ttk "classic" theme - the only
good reason I can think of to use "classic" is to preserve L&F of some
embedded-market GUI control, it's as functional-but-ugly as ever.
As of the 8.5.0, Tk apps no longer look totally out of place on the
linux desktop, much like Qt and Gtk+ apps that may not look identical
but at least don't look like they crawled out of the late 1980s / early
1990s.
It still doesn't look "as native" on Linux as on Windows or MacOSX -
none of the included themes use Qt/KDE or Gtk+ themes. There is the
possibility of someone writing Ttk themes that could blend in better by
really wrapping Qt or Gtk+ themes (the latter like Java 6 now does),
and there is someone (Georgios Petasis) working on wrapping Qt.
One of the included themes, "clam", I wouldn't describe as "hard-edged",
though I would describe it as slightly too beige for my liking. (your
users wouldn't necessarily have to deal with themes, you could
just "Ttk::setTheme clam". Note that if you want the themed widgets,
you should use ttk::button instead of tk::button etc. Though
personally, I don't mind the updated unthemed tk look except maybe its
scrollbars)
Tcl/tk 8.5.0 is in Debian/unstable . Might have now changed, but
if you install 8.4 and 8.5 in parallel, 8.4 takes precedence by default,
so you should use update-alternatives to tell your Debian system to use
8.5
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <op.t4a77uqbx6i8pv@babyfoot>
On Mon, 31 Dec 2007 22:37:10 +0100, David Golden
<············@oceanfree.net> wrote:
> Tk 8.5.0 is a large improvement in looks on linux.
> All themed (ttk, formerly "tile") widgets and the updated tk widgets
> now use antialiased fonts - which makes everything look better.
> "Out of box", it comes with 4 themes for themed (Ttk) widgets and
> updated+improved (but not actually themed, just the old color scheme
> variations) Tk widgets. The look closest to the old Tk linux look
> isn't the updated Tk widgets, it's the Ttk "classic" theme - the only
> good reason I can think of to use "classic" is to preserve L&F of some
> embedded-market GUI control, it's as functional-but-ugly as ever.
>
> As of the 8.5.0, Tk apps no longer look totally out of place on the
> linux desktop, much like Qt and Gtk+ apps that may not look identical
> but at least don't look like they crawled out of the late 1980s / early
> 1990s.
Thanks for pointing me there. Tcl/Tk 8.5 is for some reason not included
in Ubuntu 7.10, hence I never came across it. I found backports on the
web and linjked them on my blog [1]. In general I do not oppose custom
looks, as long as they are functional and at the same time somewhat nice
to look at. Especially support for antialiasing is crucial to me, and I
am glad to see that this is finally supported in tcl/tk.
When I have to revisit the GUI question for my next project, I will
definitely reconsider celtk.
[1]
http://www.washbear-network.de/peterblog/2008/01/02/lisp-and-gui-programming-revisited/
> It still doesn't look "as native" on Linux as on Windows or MacOSX -
> none of the included themes use Qt/KDE or Gtk+ themes. There is the
> possibility of someone writing Ttk themes that could blend in better by
> really wrapping Qt or Gtk+ themes (the latter like Java 6 now does),
> and there is someone (Georgios Petasis) working on wrapping Qt.
That sounds very promising. I'lll keep an eye on that. I hope there
won't be a big performance penalty attached to this (wine with an ubuntu
human theme becomes near unusable on my 3.5yr old X40).
> One of the included themes, "clam", I wouldn't describe as "hard-edged",
> though I would describe it as slightly too beige for my liking. (your
> users wouldn't necessarily have to deal with themes, you could
> just "Ttk::setTheme clam". Note that if you want the themed widgets,
> you should use ttk::button instead of tk::button etc. Though
> personally, I don't mind the updated unthemed tk look except maybe its
> scrollbars)
Alright, this is good to know. Changing to ttk:: would require some work
on the toolkit side, but this could be done, too, I think.
Again, thanks for the information,
Peter
> Tcl/tk 8.5.0 is in Debian/unstable . Might have now changed, but
> if you install 8.4 and 8.5 in parallel, 8.4 takes precedence by default,
> so you should use update-alternatives to tell your Debian system to use
> 8.5
>
>
>
>
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: David Golden
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <gdYej.24007$j7.447274@news.indigo.ie>
Peter Hildebrandt wrote:
> Thanks for pointing me there. Tcl/Tk 8.5 is for some reason not
> included in Ubuntu 7.10, hence I never came across it.
Wel, AFAIK Tcl/Tk 8.5.0 had yet to be released when Ubuntu 7.10 was
released, anyway...
From: Peter Hildebrandt
Subject: Re: How do lispers do their GUI programming anyway? (was Re: Curses alternative for Lisp?)
Date:
Message-ID: <op.t4c10fmhx6i8pv@babyfoot>
On Thu, 03 Jan 2008 04:00:28 +0100, David Golden
<············@oceanfree.net> wrote:
> Peter Hildebrandt wrote:
>
>> Thanks for pointing me there. Tcl/Tk 8.5 is for some reason not
>> included in Ubuntu 7.10, hence I never came across it.
>
> Wel, AFAIK Tcl/Tk 8.5.0 had yet to be released when Ubuntu 7.10 was
> released, anyway...
That's what I meant. I heard a debian user talking about it, did a quick
`apt-cache search tcl8.5` once I got home, found no matching packages, and
concluded I must have misunderstood something. Well, and I never
revisited the point, but stayed with my premature conclusion that tcl/tk
on linux is ugly.
Until -- thanks to your post -- I looked again at tcl/tk, found the
backports from debian unstable to ubuntu, installed them, and was glad to
see tcl/tk has finally arrived in the 21st century.
Again, thanks David for bringing that to my attention.
Peter
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Peter Hildebrandt" <·················@gmail.com> writes:
> On Thu, 03 Jan 2008 04:00:28 +0100, David Golden
> <············@oceanfree.net> wrote:
>
>> Peter Hildebrandt wrote:
>>
>>> Thanks for pointing me there. Tcl/Tk 8.5 is for some reason not
>>> included in Ubuntu 7.10, hence I never came across it.
>>
>> Wel, AFAIK Tcl/Tk 8.5.0 had yet to be released when Ubuntu 7.10 was
>> released, anyway...
>
> That's what I meant. I heard a debian user talking about it, did a
> quick `apt-cache search tcl8.5` once I got home, found no matching
> packages, and concluded I must have misunderstood something. Well,
> and I never revisited the point, but stayed with my premature
> conclusion that tcl/tk on linux is ugly.
>
> Until -- thanks to your post -- I looked again at tcl/tk, found the
> backports from debian unstable to ubuntu, installed them, and was glad
> to see tcl/tk has finally arrived in the 21st century.
>
> Again, thanks David for bringing that to my attention.
"Ditto."
It apparently doesn't play with tkirc yet, but it makes a number of
apps look a lot nicer.
--
select 'cbbrowne' || ·@' || 'linuxfinances.info';
http://linuxdatabases.info/info/emacs.html
Rules of the Evil Overlord #159. "If I burst into rebel headquarters
and find it deserted except for an odd, blinking device, I will not
walk up and investigate; I'll run like hell."
<http://www.eviloverlord.com/>
On Jan 2, 4:03 pm, "Peter Hildebrandt" <·················@gmail.com>
wrote:
>
> Alright, this is good to know. Changing to ttk:: would require some work
> on the toolkit side, but this could be done, too, I think.
celtk already uses ttk.
--andy (a quiet celtk user)
On Mon, 31 Dec 2007 16:20:33 +0100, Andreas Davour <·······@updateLIKE.uu.HELLse> wrote:
> If you have to use FFI it usually means two things. First you've
> encountered one of the things that Lisp lack, like a standard socket
> library,
Nonsense. You don't need the FFI to work with sockets and it doesn't
get any more "standard" if you do.
> or second that you are trying to do things the C way and not the
> Lisp way. If during all these years nobody have made any terminal
> handling library I'm beginning to think I'm onto case two.
Maybe nobody needed one? Or maybe the people who needed one where
content with using the FFI approach? Or maybe (gasp!) somebody wrote
such a library and dared not to release it as open source so that you
can use it for free?
> As it is low-level stuff I guess FFI is the way to go, but I'm
> beginning to wonder how lispers do their (G)UI programming anyway.
No Lisper has ever done GUI programming. That's one of the many
things you simply can't do in Lisp.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Mon, 31 Dec 2007 16:20:33 +0100, Andreas Davour
> <·······@updateLIKE.uu.HELLse> wrote:
>
>> If you have to use FFI it usually means two things. First you've
>> encountered one of the things that Lisp lack, like a standard socket
>> library,
>
> Nonsense. You don't need the FFI to work with sockets and it doesn't
> get any more "standard" if you do.
I sometimes find that the way I express myself is misunderstood, and
since English is not my native language it's no wonder. But this time
even I have a hard time understanding what I wrote. Sorry.
What I meant was that there are no sockets in the CLHS, and you have to
rely on a external library. Sometimes those are just an abstraction
layer over C. For sockets there are excellent libraries, like usocket,
and what lives beneath the hood of that one of beyond me. It works like
a charm, though! Many thanks to whomever made that puppy and decided to
share!
>> or second that you are trying to do things the C way and not the
>> Lisp way. If during all these years nobody have made any terminal
>> handling library I'm beginning to think I'm onto case two.
>
> Maybe nobody needed one? Or maybe the people who needed one where
> content with using the FFI approach? Or maybe (gasp!) somebody wrote
> such a library and dared not to release it as open source so that you
> can use it for free?
I have no problem with someone writing such a libray and not sharing,
it's their option. I just haven't heard of any. Maybe, like you said,
FFI works fine or nobody needed one. I don't know. If the latter is the
case I'm curious about what they use instead for a UI.
>> As it is low-level stuff I guess FFI is the way to go, but I'm
>> beginning to wonder how lispers do their (G)UI programming anyway.
>
> No Lisper has ever done GUI programming. That's one of the many
> things you simply can't do in Lisp.
Sorry if I seemed dense, I can understand you might sigh and be a bit
sarcastic. I'm just curous about how people do these things. I know of
CLIM (And have even written a few smallish McCLIM programs), but I
understand that it's not universally liked or used. It was just a
curious thought.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Mon, 31 Dec 2007 19:29:25 +0100, Andreas Davour <·······@updateLIKE.uu.HELLse> wrote:
> What I meant was that there are no sockets in the CLHS, and you have
> to rely on a external library. Sometimes those are just an
> abstraction layer over C. For sockets there are excellent libraries,
> like usocket, and what lives beneath the hood of that one of beyond
> me. It works like a charm, though! Many thanks to whomever made that
> puppy and decided to share!
But just to make that clear: usocket is "just" a compatibility layer.
All the CL implementations worth talking about come with their own
socket library that you can simply use /without/ the need to use /any/
external library. You only need something like usocket if you insist
on writing code that uses sockets /and/ is portable between
/different/ Lisps. (Likewise, you'll certainly have extra fun if you
want your C/C++ app to compile with gcc, Visual Studio, Metrowerks,
and Intel's compiler.)
> I have no problem with someone writing such a libray and not
> sharing, it's their option. I just haven't heard of any.
I think Pascal Bourguignon's posting should have changed that.
> Sorry if I seemed dense, I can understand you might sigh and be a
> bit sarcastic. I'm just curous about how people do these things.
I could tell you that LispWorks comes with a wonderful library called
CAPI that produces native GUIs on Windows, OS X, and Linux, and that I
have used it successfully for several commercial projects or for these
little tool:
http://weitz.de/regex-coach/
http://weitz.de/starter-pack/
I could tell you to come to the next ECLM to see some other
applications that were written using CAPI.
http://weitz.de/eclm2008/
(You could have seen similar apps at the previous ECLMs, BTW.) Or I
could tell you to download a trial version of AllegroCL and try their
GUI library.
But whenever you dare to mention these things, lots of c.l.l
inhabitants will stand up and start to chant: "No, no, no, it has to
be FREE, FREE, FREE. I'm oh-so-professional, but I can't afford to
pay 1000 bucks for a professional tool." So, I'd rather shut up...
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Mon, 31 Dec 2007 19:29:25 +0100, Andreas Davour
> <·······@updateLIKE.uu.HELLse> wrote:
>
>> What I meant was that there are no sockets in the CLHS, and you have
>> to rely on a external library. Sometimes those are just an
>> abstraction layer over C. For sockets there are excellent libraries,
>> like usocket, and what lives beneath the hood of that one of beyond
>> me. It works like a charm, though! Many thanks to whomever made that
>> puppy and decided to share!
>
> But just to make that clear: usocket is "just" a compatibility layer.
> All the CL implementations worth talking about come with their own
> socket library that you can simply use /without/ the need to use /any/
> external library. You only need something like usocket if you insist
> on writing code that uses sockets /and/ is portable between
> /different/ Lisps. (Likewise, you'll certainly have extra fun if you
> want your C/C++ app to compile with gcc, Visual Studio, Metrowerks,
> and Intel's compiler.)
I am a sucker for portability and using just ANSI standard lisp and
portable libraries is one way I try to be portable. I like it that way.
>> Sorry if I seemed dense, I can understand you might sigh and be a
>> bit sarcastic. I'm just curous about how people do these things.
>
> I could tell you that LispWorks comes with a wonderful library called
> CAPI that produces native GUIs on Windows, OS X, and Linux, and that I
> have used it successfully for several commercial projects or for these
> little tool:
>
> http://weitz.de/regex-coach/
> http://weitz.de/starter-pack/
>
> I could tell you to come to the next ECLM to see some other
> applications that were written using CAPI.
>
> http://weitz.de/eclm2008/
>
> (You could have seen similar apps at the previous ECLMs, BTW.) Or I
> could tell you to download a trial version of AllegroCL and try their
> GUI library.
>
> But whenever you dare to mention these things, lots of c.l.l
> inhabitants will stand up and start to chant: "No, no, no, it has to
> be FREE, FREE, FREE. I'm oh-so-professional, but I can't afford to
> pay 1000 bucks for a professional tool." So, I'd rather shut up...
I have not had financial stability to consider such stuff very often in
my life (and I'm not a professional programmer), and for ideological
reasons I prefer to use Free Software (as defined by the FSF) but each
to his own. It's good to know there are options. For some reason I had
in fact forgotten about CAPI. Thanks for bringing it to my attention.
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Andreas Davour <·······@updateLIKE.uu.HELLse> writes:
> ····@mail.ru (Timofei Shatrov) writes:
>
>>>> (check out curses.lisp; it also contains some bloat such as REPL
>>>> implementation; oh, there is also a whole game that uses the library)
>>>
>>>Ouch! I sense a lack, or maybe I'm into unidiomatic territory.
>>
>> I don't see how Lisp is different from C in this case. In either case
>> you have to call some external library. The fact that curses
>> implementations are written in C doesn't matter. This is extremely
>> low-level OS-specific stuff, and perhaps C is the best language to
>> implement that stuff in. Once you have FFI bindings, curses is just as
>> easy and natural to use in Lisp as in C.
>
> If you have to use FFI it usually means two things. First you've
> encountered one of the things that Lisp lack, like a standard socket
> library, or second that you are trying to do things the C way and not the
> Lisp way. If during all these years nobody have made any terminal
> handling library I'm beginning to think I'm onto case two.
Really? Even if during all these years, more terminal handling
libraries for Lisp have been made than ... terminals?
In the meantime, in clisp you can use the clisp specific SCREEN package,
or if you want to deal only with ECMA-048 (ie. ISO-6429) terminals,
you can use COM.INFORMATIMAGO.COMMON-LISP.ECMA048 to build these
control sequences.
http://darcs.informatimago.com/darcs/public/lisp/common-lisp/ecma048.lisp
> As it is low-level stuff I guess FFI is the way to go, but I'm beginning
> to wonder how lispers do their (G)UI programming anyway.
--
__Pascal_Bourguignon__ _ Software patents are endangering
() ASCII ribbon against html email (o_ the computer industry all around
/\ 1962:DO20I=1.100 //\ the world http://lpf.ai.mit.edu/
2001:my($f)=`fortune`; V_/ http://petition.eurolinux.org/
Andreas Davour <·······@updateLIKE.uu.HELLse> writes:
> So, what do people use to build text based menu systems, and to do other
> terminal based maneuvers in lisp? In C I would reach for curses, but
> what now? Any hints?
I used cl-ncurses for the beginnings of a roguelike about a year ago; it
seemed to work pretty well. There were some oddities; I couldn't tell
if they were bugs in cl-ncurses or just strangeness in ncurses itself.
--
Robert Uhl <http://public.xdi.org/=ruhl>
A doctor can bury his mistakes but an architect can only advise his
clients to plant vines. --Frank Lloyd Wright