Hello,
I have noticed that recently there is quite some work going on about
coding Lisp GUIs. Kenny Tilton is doing his CELLS stuff and some other
people are doing wxLisp.
I think we should stop for a second and think/plan before starting to
code. Otherwise we run the risk of creating just another of the lots
of GUIs that already are there.(http://www.free-soft.org/guitool/)
I mean, if we have a language as great as Lisp, shouldn't we also make
a GUI up to it's level? I was thinking about having a GUI which had
the same relation of superiority to existing GUIs as Lisp has to other
languages.
Maybe there is already a project like that? Do you know about fresco?
http://www.fresco.org/
Take a look at it. The amazing thing about it is that it isn't
language dependend at all! They use CORBA so basically any language
that supports CORBA can use this GUI(when it's finished). It makes
sense. Why should a GUI be language specific after all?
So if we create a Lisp specific GUI we should at least try to make it
use the power of Lisp. In this sense wxLisp seems like a poor choice,
since it is only a wrapper to a C++ GUI.
Maybe Kenny Tilton's CELLS is trying to achieve something really new,
I confess that I don't know enough about it.
So what should be the next(or first) logical step? We should start
collecting ideas, how should a good GUI be coded, etc... Fresco has
started like this, there are a lot of papers on that page with
scientific research about GUIs.
Ok, now start flaming if you want. I can already read it: "why don't
you start doing it then?", to which I will already answer: "My
contribution was to start this discussion." :)
...
thelifter wrote:
> Hello,
>
> I have noticed that recently there is quite some work going on about
> coding Lisp GUIs. Kenny Tilton is doing his CELLS stuff ...
<whine> no, i'm fucking around with FFIs and getting my ass kicked.
<\whine>. but i'll figure something out.
god bless the folks that conjured CL out of a multitude of Lisps. Just
the tiny domain of interfacing to C, unaddressed by the spec, produced a
ton of variation. Lord knows what the ANSI committee had to sort out.
> I mean, if we have a language as great as Lisp, shouldn't we also make
> a GUI up to it's level? I was thinking about having a GUI which had
> the same relation of superiority to existing GUIs as Lisp has to other
> languages.
I defined it as "Cello should be to other GUIs what CLOS is to other OOs."
>
> Maybe there is already a project like that? Do you know about fresco?
>
> http://www.fresco.org/
>
> Take a look at it. The amazing thing about it is that it isn't
> language dependend at all! They use CORBA so basically any language
> that supports CORBA can use this GUI(when it's finished). It makes
> sense. Why should a GUI be language specific after all?
>
> So if we create a Lisp specific GUI we should at least try to make it
> use the power of Lisp. In this sense wxLisp seems like a poor choice,
> since it is only a wrapper to a C++ GUI.
Right. I think this is something we want to be Lisp all the way down.
That's why after getting Cello working on ACL and LW I decided to shoot
myself in the foot and lose three weeks and counting trying to replace
the C Freeglut on which that success was built. Well, also to shake the
callback scheme because (a) callbacks are another source of porting pain
and (b) not all Lisps do callbacks in all environments (CMU non-X86?).
> Maybe Kenny Tilton's CELLS is trying to achieve something really new,
> I confess that I don't know enough about it.
No one does. :) Well, Garnet fans already know cool are formulaic slots.
The COSI crowd and any constraints programmer grok the power of Cells.
But as with most things not even more doc will help, ya gotta play with
the thing, and possibly only on a serious example.
>
> So what should be the next(or first) logical step? We should start
> collecting ideas, how should a good GUI be coded, etc... Fresco has
> started like this, there are a lot of papers on that page with
> scientific research about GUIs.
Nah, this task is so big a committee would never even start development.
Let us weirdos work on McCLIM, wxCL, and Cello and see what happens.
Update: I decided it is dumb to give up on a native win32 thang just
because I can't get it to work fully under ACL. So I am trying it under
Corman as a tie-breaker. Unfortunately UFFI does not support Corman, so
first I am adding Corman to UFFI. And so it goes.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> Unfortunately UFFI does not support Corman, so first I am adding
> Corman to UFFI.
Well, that's a good start... :)
Edi.
·········@gmx.net (thelifter) writes:
> Maybe there is already a project like that? Do you know about fresco?
I looked at it a few years ago (while it was called Berlin). My
impression was that although it was CORBA-based, there were many
helpful layers of C++ `Kits' on top of it that would have made life
quite difficult for people trying to use any other language. Besides
which, CORBA is tediously C++-object-model-ish anyway. It did look
kind of cool, though, and they may have changed that since.
> Ok, now start flaming if you want. I can already read it: "why don't
> you start doing it then?", to which I will already answer: "My
> contribution was to start this discussion." :)
Your contribution to what exactly?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
On 21 Feb 2003 10:31:28 -0800, Rajappa Iyer <···@panix.com> wrote:
>·········@gmx.net (thelifter) writes:
>
>> http://www.fresco.org/
>>
>> Take a look at it. The amazing thing about it is that it isn't
>> language dependend at all! They use CORBA so basically any language
>> that supports CORBA can use this GUI(when it's finished). It makes
>> sense. Why should a GUI be language specific after all?
>
>Fresco was a great idea until they decided to use CORBA with
>it. Ugly. Lisp doesn't need to do it this way.
>
>Personally, I'll wait for McCLIM which I think is the most Lisp-y of
>all GUIs I've seen so far.
>
>rsi
Fresco is a windowing system. This means it's supposed to replace
X-Windows.
Talk about making life hard... ;-)
Regs
henry
thelifter wrote:
> I have noticed that recently there is quite some work
> going on about coding Lisp GUIs. Kenny Tilton is doing his
> CELLS stuff and some other people are doing wxLisp.
Is wxLisp not intended for Scheme?
--
JB
Scheme already has a wxWindows implementation with a tool called
MrEd thats distributed as a part of the DrScheme environment. The
interface of DrScheme is written using MrEd.
"JB" <······@hotmail.com> wrote in message
····················@ID-167393.news.dfncis.de...
> thelifter wrote:
> > I have noticed that recently there is quite some work
> > going on about coding Lisp GUIs. Kenny Tilton is doing his
> > CELLS stuff and some other people are doing wxLisp.
>
> Is wxLisp not intended for Scheme?
> --
> JB
"OCID" <······@purdue.edu> wrote in message news:<············@mozo.cc.purdue.edu>...
> Scheme already has a wxWindows implementation with a tool called
> MrEd thats distributed as a part of the DrScheme environment. The
> interface of DrScheme is written using MrEd.
If you want a bad programming language with a wxWindows
implementation, I offer you C++. ;)
OCID wrote:
> Scheme already has a wxWindows implementation with a tool
> called MrEd thats distributed as a part of the DrScheme
> environment. The interface of DrScheme is written using
> MrEd.
Yes I know. They support a subset of an older version of
wxWindows.
--
JB
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> Hello,
>
> I have noticed that recently there is quite some work going on about
> coding Lisp GUIs. Kenny Tilton is doing his CELLS stuff and some other
> people are doing wxLisp.
>
> I think we should stop for a second and think/plan before starting to
> code.
``We''? Bahahahaha.
Okay, *you* think and plan, while I crank out code, okay? And then we
will call it ``our'' project. ;)