From: Kenny Tilton
Subject: cells-gtk screen shots
Date: 
Message-ID: <PZqrd.37057$Vk6.10455@twister.nyc.rr.com>
Nothing new to announce, just terribly pleased with myself for 
successfully doing HTML, CVS, and FTP all in the same day:

   http://common-lisp.net/project/cells-gtk/

Page closes with a series of lovely screen shots of the beast running 
under Linux (thanks, Klaus). If I get my butt in gear I will put up 
screen shots from win32, but guess what?, they are the same. Only not as 
pretty.

The shots reveal the extensive set of examples provided by cells-gtk 
author Vasilis Margioulas. I am still astonished. The sick thing is that 
he did this without any doc on Cells or one question to me. He says he 
used my Celtic (+ ltk cells) hack for ideas, but still...

cells-gtk runs now mostly with UFFI providing the FFI (platform was 
AllegroCL and win32) but I really butchered things in my usual fashion 
so I am loathe to put the resulting mess up on CVS. Volunteers to help 
polish are welcome to a copy of what I have hacked up so far.

btw, gtk is busting out all over. See the above for links to Rick 
Taube's lambda-gtk and Mario Mommer's lgtk, also on c-l.net.

<thinkingoutloud> Damn, we should join forces on the FFI part anyway. I 
dig that FFIGEN stuff over on lambda-gtk. That can be auto-converted to 
UFFI and then UFFI needs to be extended for callbacks and CLisp, as well 
as cleanly converting between Lisp values and C (eg, C boolean becomes 
Lisp t/nil transparently). <\thinkingoutloud>

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

From: Jon Boone
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <m3r7m9y55z.fsf@spiritus.delamancha.org>
Kenny Tilton <·······@nyc.rr.com> writes:

> Nothing new to announce, just terribly pleased with myself for
> successfully doing HTML, CVS, and FTP all in the same day:
>
>    http://common-lisp.net/project/cells-gtk/

    Is the Mac version done yet?

--jon
From: David Steuber
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <874qj5sese.fsf@david-steuber.com>
Jon Boone <········@delamancha.org> writes:

> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> > Nothing new to announce, just terribly pleased with myself for
> > successfully doing HTML, CVS, and FTP all in the same day:
> >
> >    http://common-lisp.net/project/cells-gtk/
> 
>     Is the Mac version done yet?

Heh!  I was wondering the same thing!

Except I want an Aqua compliant GUI toolkit for OpenMCL (and 'SBCL
'CLISP) that is code portable to Linux or that OS from Redmond.

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <A%urd.37206$Vk6.20237@twister.nyc.rr.com>
David Steuber wrote:
> Jon Boone <········@delamancha.org> writes:
> 
> 
>>Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>
>>>Nothing new to announce, just terribly pleased with myself for
>>>successfully doing HTML, CVS, and FTP all in the same day:
>>>
>>>   http://common-lisp.net/project/cells-gtk/
>>
>>    Is the Mac version done yet?
> 
> 
> Heh!  I was wondering the same thing!
> 
> Except I want an Aqua compliant GUI toolkit for OpenMCL (and 'SBCL
> 'CLISP) that is code portable to Linux or that OS from Redmond.

Sorry, not my table. but I'll tell your GTK+2/aqua open source fairy you 
were looking for her.

:)

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Klaus Weidner
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <Xvxrd.6047572$6p.964656@news.easynews.com>
On 2004-12-02, David Steuber <·····@david-steuber.com> wrote:
> Jon Boone <········@delamancha.org> writes:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>> > Nothing new to announce, just terribly pleased with myself for
>> > successfully doing HTML, CVS, and FTP all in the same day:
>> >
>> >    http://common-lisp.net/project/cells-gtk/
>> 
>>     Is the Mac version done yet?
>
> Heh!  I was wondering the same thing!
>
> Except I want an Aqua compliant GUI toolkit for OpenMCL (and 'SBCL
> 'CLISP) that is code portable to Linux or that OS from Redmond.

How about UFFIing wxWidgets (aka wxWindows) which is a higher-level abstraction
that uses the platform native toolkit on each supported platform? For example,
it automatically puts the menu bar on the top edge of the screen instead of in
the window when running on a Mac. It has been ported to lots of languages.

Some screenshots:

	http://wxwidgets.org/screen03.htm

[ Hmmm, a bit of googling... it appears that there is an unfinished project
  wxCL:

  	http://www.olivfabric.de/content/on-wxcl.html
	http://sourceforge.net/projects/wxlisp
]

-Klaus
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <%_zrd.18391$Yh2.6896437@twister.nyc.rr.com>
Klaus Weidner wrote:
> On 2004-12-02, David Steuber <·····@david-steuber.com> wrote:
> 
>>Jon Boone <········@delamancha.org> writes:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>>Nothing new to announce, just terribly pleased with myself for
>>>>successfully doing HTML, CVS, and FTP all in the same day:
>>>>
>>>>   http://common-lisp.net/project/cells-gtk/
>>>
>>>    Is the Mac version done yet?
>>
>>Heh!  I was wondering the same thing!
>>
>>Except I want an Aqua compliant GUI toolkit for OpenMCL (and 'SBCL
>>'CLISP) that is code portable to Linux or that OS from Redmond.
> 
> 
> How about UFFIing wxWidgets (aka wxWindows) which is a higher-level abstraction
> that uses the platform native toolkit on each supported platform?

OK, but (a) Gtk is native as well, IIANM, and (b) the C++ thang will 
require a whole layer of C glue. Perhaps the wxPython glue could be 
ripped off. i am not saying it is a hard task, just a little tedious. 
And if in the end one arrives back at GTK+, is thw higher-level 
abstraction worth it? (I am asking, I know nothing of the differences 
between GTK+ and wxWidgets.

My guess is the best approach is: don't FFI to wxWidgets, /translate it/ 
to CLOS/CL. This can be done gradually: take the most horrific aspect of 
GTk which is neatly encapsulated by some wxWidget higher-order class and 
port just that to CLOS.

Meanwhile, my whining brought a Lispworks volunteer out of the woodwork, 
so I am going to kill another day on cells-gtk trying to score that 
checkbox, first on win32, then os/x.

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Cameron MacKinnon
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <EfydnYYXnPg4TjPcRVn-2g@golden.net>
Kenny Tilton wrote:
> 
> My guess is the best approach is: don't FFI to wxWidgets, /translate it/ 
> to CLOS/CL. This can be done gradually: take the most horrific aspect of 
> GTk which is neatly encapsulated by some wxWidget higher-order class and 
> port just that to CLOS.

Funny, I was just reading a Richard Fateman paper. From a footnote: 
"Could Bailey's suite of routines be completely rewritten in Lisp? Yes, 
see Appendix A. But we would like to build on Bailey's shoulders, not 
his toes."
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <BfBrd.18392$Yh2.6913594@twister.nyc.rr.com>
Cameron MacKinnon wrote:

> Kenny Tilton wrote:
> 
>>
>> My guess is the best approach is: don't FFI to wxWidgets, /translate 
>> it/ to CLOS/CL. This can be done gradually: take the most horrific 
>> aspect of GTk which is neatly encapsulated by some wxWidget 
>> higher-order class and port just that to CLOS.
> 
> 
> Funny, I was just reading a Richard Fateman paper. From a footnote: 
> "Could Bailey's suite of routines be completely rewritten in Lisp? Yes, 
> see Appendix A. But we would like to build on Bailey's shoulders, not 
> his toes."
> 

These calls are always tough. Here is the context for that mot:

"But all such Lisp implementations (including our own earlier work) 
suffer a major (although non-technical) flaw: There are too few 
programmers to maintain such a package in the face of continually 
improving algorithms, changing Lisp environments, and even changing 
computer architectures. For efficiency, it is generally much better to 
re-use a state-of-the-art package, written by another person who is an 
expert on the latest algorithmic advances and perhaps polished for the 
latest hardware wrinkles, than to implement a an elaborate algorithm in 
your own language and system. Fortunately, David H. Bailey has done an 
excellent job of building a multiple-precision package in a Fortran3. To 
quote from Bailey's abstract[1] describing MPFUN:

"This package features (1) virtually universal portability, (2) high 
performance, especially on vector supercomputers, (3) advanced 
algorithms, including FFT-based multiplication and quadratically 
convergent algorithms for ss, exp and log, and (4) extensive 
self-checking and debug facilities that permit the package to be used as 
a rigorous system integrity test. "

Well, that kind of reuse is what we do by using Gtk+, which despite that 
+ in its name can be reached from C hence any decent Lisp FFI. So we are 
not standing on the toes. And climbing any higher begins by creating a 
huge amount of C glue which is hard-coded to match the underlying C++. 
When Bailey's internals change, no problem. When wxWidgets changes, it 
is time to get back to work on the C glue.

The analogy fails again when you consider what wxWidgets provides over 
Gtk+: abstraction. The above context makes clear that Bailey was 
insulating the Lisp users from (a) hard problems and (b) shifting sands. 
But abstraction is what Lisp does best. A Lisp wxWidget would be easy 
work, and the abstractions would come out better. As for shifting sands, 
  I wager the greater pace of change is in wxWidgets, and, again, that 
means the Lisp applications and C glue would be chasing a more unstable 
product.

Finally, the relationship between an application and its GUI has a lot 
more wires than a maths library. Again the comparison fails. How about 
debugging? i would rather get a backtrace from a Lisp wxWidget than one 
in C++.

As I said, these things are always a judgment call. Not reinventing 
OpenGL was pretty easy. Porting FTGL to Lisp would be a snap but offer 
little. etc etc.

kenny


-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Cameron MacKinnon
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <xfSdnSJod4dh8zLcRVn-3Q@golden.net>
Kenny Tilton wrote:
> 
> 
> Cameron MacKinnon wrote:
> 
>> Funny, I was just reading a Richard Fateman paper. From a footnote: 
>> "Could Bailey's suite of routines be completely rewritten in Lisp? 
>> Yes, see Appendix A. But we would like to build on Bailey's shoulders, 
>> not his toes."
>>
> 
> These calls are always tough. Here is the context for that mot:
...

Hey, no fair outing that I was reading about Fortran! You do seem to 
know your Fateman, though.

Don't get touchy, I just loved the extension of the "standing on the 
shoulders of giants" metaphor and wanted to share. I continue to cheer 
your progress as you and your band of merry men work at putting a 
pretty, cross-platform face on Lisp.

BTW: WTF?

 > D, L d a l t a t l n w b.

Dude, Lisp does a lot that a traditional language never will be.
Dude, Lisp doesn't always
defines a language that a true l--- never will be
never was beautiful.
agree lists that are trivial look nasty without
doesn't always look


I give up.
From: David Steuber
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87r7m8vb8k.fsf@david-steuber.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> OK, but (a) Gtk is native as well, IIANM, and (b) the C++ thang will
> require a whole layer of C glue. Perhaps the wxPython glue could be
> ripped off. i am not saying it is a hard task, just a little
> tedious. And if in the end one arrives back at GTK+, is thw
> higher-level abstraction worth it? (I am asking, I know nothing of the
> differences between GTK+ and wxWidgets.

Isn't GTK+ a C++ wrapper around GTK?  If so, then CLOS would suit
around GTK I would think.

I agree with Mikel's response about non Aqua compliance on OS X.
Speaking strictly blue sky here, I think it would probably be neat to
have a CLOS GUI library that worked across Lisp implementations that
had an Aqua compliant Carbon back end on OS X and used GTK on Linux,
other Unixes and Windows.  Unix has no CUA like guidelines that I am
aware of, so there are no user expectations.  Windows does, but who
really likes to use that anyway?  I guess what I am saying is port
Aqua style to other OSs (to a limited extent).

I've seen iTunes on XP, and it looks a heck of a lot like the OS X
version.  I don't know how much work Apple put into porting the Carbon
foundation used over to Windows.  I don't care to try that sort of
porting myself.

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1
From: William Bland
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <pan.2004.12.02.17.58.32.265757@abstractnonsense.com>
On Thu, 02 Dec 2004 12:52:27 -0500, David Steuber wrote:

> Isn't GTK+ a C++ wrapper around GTK?

No, GTK+ is all C.  There is a C++ wrapper that is named GTK--

Cheers,
	Bill.
From: David Steuber
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87k6s0pe8r.fsf@david-steuber.com>
William Bland <·······@abstractnonsense.com> writes:

> On Thu, 02 Dec 2004 12:52:27 -0500, David Steuber wrote:
> 
> > Isn't GTK+ a C++ wrapper around GTK?
> 
> No, GTK+ is all C.  There is a C++ wrapper that is named GTK--

Ah!  Right you are.  I forgot that the C++ wrapper was named GTK--.
Damn Unix humor.

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1
From: Daniel Barlow
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87brdcinsh.fsf@noetbook.telent.net>
David Steuber <·····@david-steuber.com> writes:

> Isn't GTK+ a C++ wrapper around GTK?  

No.  GTK+ is the official name of the library/collection of libraries
that most people call Gtk, and it's written in C.

http://www.gtk.org/faq/#AEN90


-dan

-- 
"please make sure that the person is your friend before you confirm"
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <X2Jrd.18416$Yh2.7026799@twister.nyc.rr.com>
David Steuber wrote:

> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>OK, but (a) Gtk is native as well, IIANM, and (b) the C++ thang will
>>require a whole layer of C glue. Perhaps the wxPython glue could be
>>ripped off. i am not saying it is a hard task, just a little
>>tedious. And if in the end one arrives back at GTK+, is thw
>>higher-level abstraction worth it? (I am asking, I know nothing of the
>>differences between GTK+ and wxWidgets.
> 
> 
> Isn't GTK+ a C++ wrapper around GTK?  If so, then CLOS would suit
> around GTK I would think.
> 
> I agree with Mikel's response about non Aqua compliance on OS X.
> Speaking strictly blue sky here, I think it would probably be neat to
> have a CLOS GUI library that worked across Lisp implementations that
> had an Aqua compliant Carbon back end on OS X and used GTK on Linux,
> other Unixes and Windows.  Unix has no CUA like guidelines that I am
> aware of, so there are no user expectations.  Windows does, but who
> really likes to use that anyway?

Hang on. We are talking about user acceptance and the need to be native. 
I think you just made a discontinuous leap into (the always delightful 
and needed) Windows-bashing.

   I guess what I am saying is port
> Aqua style to other OSs (to a limited extent).
> 
> I've seen iTunes on XP, and it looks a heck of a lot like the OS X
> version.

OK, so now all of a sudden my apps do /not/ have to have native look and 
feel? Yippee! :) Actually, I think all of iTunes diverges from standard 
Mac look and feel in favor of some better choices made by <spit> Redmond.

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <oaKrd.27569$zx1.353@newssvr13.news.prodigy.com>
Kenny Tilton wrote:

> 
> 
> David Steuber wrote:

>   I guess what I am saying is port
> 
>> Aqua style to other OSs (to a limited extent).
>>
>> I've seen iTunes on XP, and it looks a heck of a lot like the OS X
>> version.
> 
> 
> OK, so now all of a sudden my apps do /not/ have to have native look and 
> feel? Yippee! :) Actually, I think all of iTunes diverges from standard 
> Mac look and feel in favor of some better choices made by <spit> Redmond.

He's saying that Windows users care less about the UI standards than Mac 
users. Maybe, maybe not. It is true that diverging from Mac UI standards 
is basically begging Mac users to hate your app.
From: Lars Brinkhoff
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <857jo0efuz.fsf@junk.nocrew.org>
David Steuber <·····@david-steuber.com> writes:
> Isn't GTK+ a C++ wrapper around GTK?

No.  The C++ bindings for GTK+ is called gtkmm (or GTK--).

See also:
http://www.gtk.org/faq/#AEN90

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <X5Krd.27568$zx1.19326@newssvr13.news.prodigy.com>
David Steuber wrote:


> I've seen iTunes on XP, and it looks a heck of a lot like the OS X
> version.  I don't know how much work Apple put into porting the Carbon
> foundation used over to Windows.  

I do; I was there when it was done.

>I don't care to try that sort of
> porting myself.

You are wise, grasshopper.
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <URFrd.53114$QJ3.16160@newssvr21.news.prodigy.com>
Kenny Tilton wrote:
> 
> 
> Klaus Weidner wrote:
> 
>> On 2004-12-02, David Steuber <·····@david-steuber.com> wrote:
>>
>>> Jon Boone <········@delamancha.org> writes:
>>>
>>>> Kenny Tilton <·······@nyc.rr.com> writes:
>>>>
>>>>> Nothing new to announce, just terribly pleased with myself for
>>>>> successfully doing HTML, CVS, and FTP all in the same day:
>>>>>
>>>>>   http://common-lisp.net/project/cells-gtk/
>>>>
>>>>
>>>>    Is the Mac version done yet?
>>>
>>>
>>> Heh!  I was wondering the same thing!
>>>
>>> Except I want an Aqua compliant GUI toolkit for OpenMCL (and 'SBCL
>>> 'CLISP) that is code portable to Linux or that OS from Redmond.
>>
>>
>>
>> How about UFFIing wxWidgets (aka wxWindows) which is a higher-level 
>> abstraction
>> that uses the platform native toolkit on each supported platform?
> 
> 
> OK, but (a) Gtk is native as well, IIANM

Gtk is native code, but not necessarily native widgets. For example, the 
Gtk on X11 (that is, the complete and usable one) is not Aqua-compliant. 
According to the wxWidgets FAQ, an Aqua-compliant wxWidgets is under 
construction.

Making a non-Aqua-compliant GUI app for OS X is not a good idea; it 
handicaps adoption fairly severely.
From: Neo-LISPer
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <1210433.KNHNF4qhQV@yahoo.com>
mikel wrote:

> Kenny Tilton wrote:
>> 
>> 
>> Klaus Weidner wrote:
>> 
>>> On 2004-12-02, David Steuber <·····@david-steuber.com> wrote:
>>>
>>>> Jon Boone <········@delamancha.org> writes:
>>>>
>>>>> Kenny Tilton <·······@nyc.rr.com> writes:
>>>>>
>>>>>> Nothing new to announce, just terribly pleased with myself for
>>>>>> successfully doing HTML, CVS, and FTP all in the same day:
>>>>>>
>>>>>>   http://common-lisp.net/project/cells-gtk/
>>>>>
>>>>>
>>>>>    Is the Mac version done yet?
>>>>
>>>>
>>>> Heh!  I was wondering the same thing!
>>>>
>>>> Except I want an Aqua compliant GUI toolkit for OpenMCL (and 'SBCL
>>>> 'CLISP) that is code portable to Linux or that OS from Redmond.
>>>
>>>
>>>
>>> How about UFFIing wxWidgets (aka wxWindows) which is a higher-level
>>> abstraction
>>> that uses the platform native toolkit on each supported platform?
>> 
>> 
>> OK, but (a) Gtk is native as well, IIANM
> 
> Gtk is native code, but not necessarily native widgets. For example, the
> Gtk on X11 (that is, the complete and usable one) is not Aqua-compliant.
> According to the wxWidgets FAQ, an Aqua-compliant wxWidgets is under
> construction.
> 
> Making a non-Aqua-compliant GUI app for OS X is not a good idea; it
> handicaps adoption fairly severely.

I don't know about Mac OS X specifically, but native look and feel does not
require wx or C++. All you need is the right theme for gtk, for example see
http://gtk-wimp.sourceforge.net/screenshots/
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <t8Ird.18410$Yh2.7010247@twister.nyc.rr.com>
mikel wrote:

> Kenny Tilton wrote:
> 
>>
>>
>> Klaus Weidner wrote:
>>
>>> On 2004-12-02, David Steuber <·····@david-steuber.com> wrote:
>>>
>>>> Jon Boone <········@delamancha.org> writes:
>>>>
>>>>> Kenny Tilton <·······@nyc.rr.com> writes:
>>>>>
>>>>>> Nothing new to announce, just terribly pleased with myself for
>>>>>> successfully doing HTML, CVS, and FTP all in the same day:
>>>>>>
>>>>>>   http://common-lisp.net/project/cells-gtk/
>>>>>
>>>>>
>>>>>
>>>>>    Is the Mac version done yet?
>>>>
>>>>
>>>>
>>>> Heh!  I was wondering the same thing!
>>>>
>>>> Except I want an Aqua compliant GUI toolkit for OpenMCL (and 'SBCL
>>>> 'CLISP) that is code portable to Linux or that OS from Redmond.
>>>
>>>
>>>
>>>
>>> How about UFFIing wxWidgets (aka wxWindows) which is a higher-level 
>>> abstraction
>>> that uses the platform native toolkit on each supported platform?
>>
>>
>>
>> OK, but (a) Gtk is native as well, IIANM
> 
> 

[Aside: while googling around I found someone not only greenspunning in 
C++ but also doing Cells in C++:
 
http://www.litwindow.com/Library/RapidUI_Article_1/rapidui_article_1.htm

Not that I am surprised anymore. Of course Garnet became C++ Amulet in 
yet another example of successful Lisp being ported to C++ -- and dying. 
They shoulda stood with Lisp.]

> Gtk is native code, but not necessarily native widgets. For example, the 
> Gtk on X11 (that is, the complete and usable one) is not Aqua-compliant. 
> According to the wxWidgets FAQ, an Aqua-compliant wxWidgets is under 
> construction.

There is a Gtk-Aqua effort, but it looks quiet:

    http://gtk-osx.sourceforge.net/

The wxMac project looks livelier, with a release in October.

> 
> Making a non-Aqua-compliant GUI app for OS X is not a good idea; it 
> handicaps adoption fairly severely.

Uh, I think this is where I came in. <g> Not sure what Aqua-compliant 
means. I have been playing a few games lately just to have something 
else to do with my G5, and I cannot say I have seen Aqua anywhere inside 
the window border. Menus and dialogs, yes. Is that what you mean? If so, 
I agree, and that is something Cello will have to come to grips with 
eventually in some OS-conditionalized code (unless wxWidgets replaces 
Glut -- Those wxOpengl examples got me thinking).

kt

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <B3Krd.27566$zx1.22485@newssvr13.news.prodigy.com>
Kenny Tilton wrote:
> 
> 
> mikel wrote:
> 
>> Kenny Tilton wrote:
>>
>>>
>>>
>>> Klaus Weidner wrote:
>>>
>>>> On 2004-12-02, David Steuber <·····@david-steuber.com> wrote:
>>>>
>>>>> Jon Boone <········@delamancha.org> writes:
>>>>>
>>>>>> Kenny Tilton <·······@nyc.rr.com> writes:
>>>>>>
>>>>>>> Nothing new to announce, just terribly pleased with myself for
>>>>>>> successfully doing HTML, CVS, and FTP all in the same day:
>>>>>>>
>>>>>>>   http://common-lisp.net/project/cells-gtk/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    Is the Mac version done yet?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Heh!  I was wondering the same thing!
>>>>>
>>>>> Except I want an Aqua compliant GUI toolkit for OpenMCL (and 'SBCL
>>>>> 'CLISP) that is code portable to Linux or that OS from Redmond.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> How about UFFIing wxWidgets (aka wxWindows) which is a higher-level 
>>>> abstraction
>>>> that uses the platform native toolkit on each supported platform?
>>>
>>>
>>>
>>>
>>> OK, but (a) Gtk is native as well, IIANM
>>
>>
>>
> 
> [Aside: while googling around I found someone not only greenspunning in 
> C++ but also doing Cells in C++:
> 
> http://www.litwindow.com/Library/RapidUI_Article_1/rapidui_article_1.htm
> 
> Not that I am surprised anymore. Of course Garnet became C++ Amulet in 
> yet another example of successful Lisp being ported to C++ -- and dying. 
> They shoulda stood with Lisp.]
> 
>> Gtk is native code, but not necessarily native widgets. For example, 
>> the Gtk on X11 (that is, the complete and usable one) is not 
>> Aqua-compliant. According to the wxWidgets FAQ, an Aqua-compliant 
>> wxWidgets is under construction.
> 
> 
> There is a Gtk-Aqua effort, but it looks quiet:
> 
>    http://gtk-osx.sourceforge.net/
> 
> The wxMac project looks livelier, with a release in October.
> 
>>
>> Making a non-Aqua-compliant GUI app for OS X is not a good idea; it 
>> handicaps adoption fairly severely.
> 
> 
> Uh, I think this is where I came in. <g> Not sure what Aqua-compliant 
> means.

It's actually a bit complicated, and means things like:

(1) using the standard Apple-supplied widgets

(2) using them the way Apple says you are supposed to, except in the 
very unusual case that you come up with a better way (and even then it 
mostly only works if all the rest of your app does things the standard way)

(3) implementing a bunch of supporting junk that makes apps interoperate 
in the way users expect (drag and drop, services, spell-checking 
support, standard support for user preferences, standard support for 
accelerator keys, alias resolution, proper customization of Open and 
Save panels, etc. etc.)

(4) laying out graphical elements the way you're supposed to (Interface 
Builder actually displays guidelines when you're dragging widgets around 
to show you where they're supposed to go)

...and more stuff that I'm sure I haven't thought of off the top of my head.

> I have been playing a few games lately just to have something 
> else to do with my G5, and I cannot say I have seen Aqua anywhere inside 
> the window border. Menus and dialogs, yes. Is that what you mean? If so, 
> I agree, and that is something Cello will have to come to grips with 
> eventually in some OS-conditionalized code (unless wxWidgets replaces 
> Glut -- Those wxOpengl examples got me thinking).

Games can get away with ignoring Aqua in proportion to how fun and 
must-have they are. Some apps (e.g. Blender and Gimp) can get away with 
ignoring Aqua because they already have large non-Mac-using user bases 
who are accustomed to using them on other platforms, and find the 
familiar UI acceptable.

Launching a new app on OS X without understanding how to make it 
Aqua-like is probably a waste of resources in most cases. There are 
exceptions; for instance, there are modestly successful Java apps, but 
that's likely because they have a lot of help from Apple, which went far 
out of its way to make Java apps look mostly like Aqua apps. (It's even 
possible to make Java apps that really are Aqua apps, but most Java 
programmers don't do that because it means using Apple's proprietary 
framework libraries instead of Sun's portable ones).
From: Oyvin Halfdan Thuv
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <41AF4479.4080308@no.spam.oyvins.net>
mikel wrote:

> Gtk is native code, but not necessarily native widgets. For example, the 
> Gtk on X11 (that is, the complete and usable one) is not Aqua-compliant. 
> According to the wxWidgets FAQ, an Aqua-compliant wxWidgets is under 
> construction.
> 
> Making a non-Aqua-compliant GUI app for OS X is not a good idea; it 
> handicaps adoption fairly severely.

Isn't LTK (TK) native widgets on X11(motif), Aqua and Win32?

-- 
�yvin
From: Bruce Stephens
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87d5xsd1xp.fsf@cenderis.demon.co.uk>
Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> writes:

[...]

> Isn't LTK (TK) native widgets on X11(motif), Aqua and Win32?

No.

More precisely, it's not native on anything.  It looks a bit like
Motif (or can do, depending on colours), but I don't think it ever
used Motif libraries.

When Tile <http://wiki.tcl.tk/11075> is integrated, there'll be the
potential for native widgets, and I'd guess Gtk+ and win32 will be in
there from the start; quite possibly Aqua too.  But that hasn't
happened yet.
From: Peter Herth
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <conmso$4mf$1@newsreader2.netcologne.de>
Bruce Stephens wrote:
> Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> writes:
> 
> [...]
> 
> 
>>Isn't LTK (TK) native widgets on X11(motif), Aqua and Win32?
> 
> 
> No.
> 
> More precisely, it's not native on anything.  It looks a bit like
> Motif (or can do, depending on colours), but I don't think it ever
> used Motif libraries.

Sorry, but you are wrong. Tk uses native widgets of the platform.
The Linux version uses Motif-style widgets, and TkAqua definitely
uses Aqua widgets.

Peter
From: Bruce Stephens
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87k6s01ix2.fsf@cenderis.demon.co.uk>
Peter Herth <·····@netcologne.de> writes:

[...]

> Sorry, but you are wrong. Tk uses native widgets of the platform.
> The Linux version uses Motif-style widgets, and TkAqua definitely
> uses Aqua widgets.

Motif-style, yes, but it's not using Motif.  And (as I mentioned) you
can get Tile, which gives you native widgets on Unix and Windows (for
some definition of native).  I didn't know about TkAqua, but it's not
surprising that it exists.

However, if you download the standard Tcl and Tk from
<http://tcl.sourceforge.net/>, then as far as I know that won't give
you native widgets on any platform.
From: Matthias
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <36wsm6k1zp9.fsf@hundertwasser.ti.uni-mannheim.de>
Bruce Stephens <············@cenderis.demon.co.uk> writes:
> However, if you download the standard Tcl and Tk from
> <http://tcl.sourceforge.net/>, then as far as I know that won't give
> you native widgets on any platform.

Well, on http://www.tcl.tk/software/tcltk/8.0.html the number 1 item
on the "what's new" list is:

Native look and feel. The widgets have been rewritten to provide
(nearly?) native look and feel on the Macintosh and PC.
From: Oyvin Halfdan Thuv
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <covoj0$su5$1@orkan.itea.ntnu.no>
Matthias wrote:
> Bruce Stephens <············@cenderis.demon.co.uk> writes:
> 
>>However, if you download the standard Tcl and Tk from
>><http://tcl.sourceforge.net/>, then as far as I know that won't give
>>you native widgets on any platform.
> 
> 
> Well, on http://www.tcl.tk/software/tcltk/8.0.html the number 1 item
> on the "what's new" list is:
> 
> Native look and feel. The widgets have been rewritten to provide
> (nearly?) native look and feel on the Macintosh and PC.

also:

"Many widgets, including scrollbars, menus, and the button family, are 
implemented with native platform widgets. Others, such as entries and 
texts, have been modified to emulate native look and feel."

on http://www.tcl.tk/software/tcltk/8.4.html:

"- native Aqua support for OS X"

Anyway, the toolkit seems quite stable and looks like native. I think 
Peter Herth has done a remarkable job binding it to Lisp, and I think it 
could be a very good choise for simple(?) platform independent GUI's.

-- 
�yvin
From: Peter Herth
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <covq6q$n9l$1@newsreader2.netcologne.de>
Oyvin Halfdan Thuv wrote:

> Anyway, the toolkit seems quite stable and looks like native. I think 
> Peter Herth has done a remarkable job binding it to Lisp, and I think it 
> could be a very good choise for simple(?) platform independent GUI's.

Thank you :)

Peter

-- 
pet project: http://dawn.netcologne.de
homepage:    http://www.peter-herth.de
lisp stuff:  http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: Bruce Stephens
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87r7m49rde.fsf@cenderis.demon.co.uk>
Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> writes:

[...]

> "Many widgets, including scrollbars, menus, and the button family, are
> implemented with native platform widgets. Others, such as entries and
> texts, have been modified to emulate native look and feel."

I guess to some extent it's a question of personal taste: at least one
Mac person has told me that Tk's not native enough for them, and that
they didn't much like it on Windows either.

> on http://www.tcl.tk/software/tcltk/8.4.html:
>
> "- native Aqua support for OS X"

Yeah, I concede that one.  It's new, and (not having a Mac) I wouldn't
be able to judge it anyway.
From: GP lisper
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <1102451865.cc76de897ebd95917d1b48c4e1aa49af@teranews>
On Mon, 06 Dec 2004 00:56:13 +0000, <············@cenderis.demon.co.uk> wrote:
> Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> writes:
>
> [...]
>
>> "Many widgets, including scrollbars, menus, and the button family, are
>> implemented with native platform widgets. Others, such as entries and
>> texts, have been modified to emulate native look and feel."
>
> I guess to some extent it's a question of personal taste: at least one
> Mac person has told me that Tk's not native enough for them, and that
> they didn't much like it on Windows either.


I'm still chuckling over the "native widgets" idea.  Why the stuff
produced under a delivery schedule should be deemed superior is beyond
me.  It's like saying that a painting not done in the style of 'Artist
X' is no good.

Care that the backend produces correct answers, not that you have
pretty buttons to push.  The piece that interests me in this thread is
the 'minimal work to connect up a GUI'.  It would be interesting to
see a HowTo for noobs...


-- 
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Carl Shapiro
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <ouymzwp6b03.fsf@panix3.panix.com>
GP lisper <········@CloudDancer.com> writes:

> I'm still chuckling over the "native widgets" idea.  Why the stuff
> produced under a delivery schedule should be deemed superior is beyond
> me.  It's like saying that a painting not done in the style of 'Artist
> X' is no good.

Native widgets export interfaces which are seldom reimplemented by the
programmer who sets out to create a widget pallet of his own design.
People who use alternative input methods (speech, handwriting), rely
heavily on keyboard accelerators, or script user interfaces will
quickly identify applications which are not using standard widgets as
they will often fall short of their expectations.

With proper care, you could create non-native widgets which are
functionally identical to their native counterparts.  However, after
implementing all details of the human interface guidelines of your
target platform, developing a test plan for it, and regularly testing
the custom interface elements, you will have spent far more time than
you would have otherwise devoted to just calling a library function to
draw a native button on your screen.

Solo cowboy programmers may be able to cut corners in the development
process, but when working inside an organization focused on software
engineering, I doubt you will make your project deadlines with these
added burdens.
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <VMptd.55810$QJ3.40408@newssvr21.news.prodigy.com>
Carl Shapiro wrote:
> GP lisper <········@CloudDancer.com> writes:
> 
> 
>>I'm still chuckling over the "native widgets" idea.  Why the stuff
>>produced under a delivery schedule should be deemed superior is beyond
>>me.  It's like saying that a painting not done in the style of 'Artist
>>X' is no good.
> 
> 
> Native widgets export interfaces which are seldom reimplemented by the
> programmer who sets out to create a widget pallet of his own design.
> People who use alternative input methods (speech, handwriting), rely
> heavily on keyboard accelerators, or script user interfaces will
> quickly identify applications which are not using standard widgets as
> they will often fall short of their expectations.
> 
> With proper care, you could create non-native widgets which are
> functionally identical to their native counterparts.  However, after
> implementing all details of the human interface guidelines of your
> target platform, developing a test plan for it, and regularly testing
> the custom interface elements, you will have spent far more time than
> you would have otherwise devoted to just calling a library function to
> draw a native button on your screen.
> 
> Solo cowboy programmers may be able to cut corners in the development
> process, but when working inside an organization focused on software
> engineering, I doubt you will make your project deadlines with these
> added burdens.

Right.

In addition, regular users of a given platform can usually spot, and be 
annoyed by, even slight deviations from the appearance and behavior of 
the widgets they are used to. The "solo cowboy" programmer may argue 
that his novel widget set is functionally equivalent or even superor, 
and so users should not mind if it differs a little, but the fact of the 
matter is that users typically do mind. That being the case, using 
something other than 'native widgets' in an application amounts to an 
implicit claim that your software will be so amazingly great that you 
can spit in the faces of your prospective users and they'll still love you.

If you can, great. Odds are, you can't.
From: Kenny Tilton
Subject: Lisp GUI How-to [was Re: cells-gtk screen shots]
Date: 
Message-ID: <DHotd.66885$Vk6.16259@twister.nyc.rr.com>
GP lisper wrote:

> pretty buttons to push.  The piece that interests me in this thread is
> the 'minimal work to connect up a GUI'.  It would be interesting to
> see a HowTo for noobs...

Doc is hard. Meet us GUI providers half way. If you cook up a good 
/specific/ example(s) you would like to see in a "how to", I will 
provide the code for Cello, cells-gtk, and Celtic. (I should have 
spelled that last one Celtk so I would not have to explain it all the 
time. Hmmm....rewrite!)

Other Lisp GUI developers can do the same. Maybe we use cl-pdf to build 
manuals for each lib? Or is it one big Lisp GUI how-to? Thoughts?

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: GP lisper
Subject: Re: Lisp GUI How-to [was Re: cells-gtk screen shots]
Date: 
Message-ID: <1102565939.e24abbd08886745e7c35724e70181adb@teranews>
On Tue, 07 Dec 2004 20:49:39 GMT, <·······@nyc.rr.com> wrote:
>
>
> GP lisper wrote:
>
>> pretty buttons to push.  The piece that interests me in this thread is
>> the 'minimal work to connect up a GUI'.  It would be interesting to
>> see a HowTo for noobs...
>
> Doc is hard. Meet us GUI providers half way. If you cook up a good 
> /specific/ example(s) you would like to see in a "how to", I will 
> provide the code for Cello, cells-gtk, and Celtic. (I should have 
> spelled that last one Celtk so I would not have to explain it all the 
> time. Hmmm....rewrite!)

That's tough at the moment Kenny, all I have to go on are the
screenshots (cannot get windoze and cygwin to play together).  I would
think that the best suggestion (at the moment) would be describing how
to put together one of the screenshots.


-- 
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Kenny Tilton
Subject: Re: Lisp GUI How-to [was Re: cells-gtk screen shots]
Date: 
Message-ID: <wMRtd.72612$Vk6.8533@twister.nyc.rr.com>
GP lisper wrote:

> On Tue, 07 Dec 2004 20:49:39 GMT, <·······@nyc.rr.com> wrote:
> 
>>
>>GP lisper wrote:
>>
>>
>>>pretty buttons to push.  The piece that interests me in this thread is
>>>the 'minimal work to connect up a GUI'.  It would be interesting to
>>>see a HowTo for noobs...
>>
>>Doc is hard. Meet us GUI providers half way. If you cook up a good 
>>/specific/ example(s) you would like to see in a "how to", I will 
>>provide the code for Cello, cells-gtk, and Celtic. (I should have 
>>spelled that last one Celtk so I would not have to explain it all the 
>>time. Hmmm....rewrite!)
> 
> 
> That's tough at the moment Kenny, all I have to go on are the
> screenshots (cannot get windoze and cygwin to play together).  I would
> think that the best suggestion (at the moment) would be describing how
> to put together one of the screenshots.

Good news: Cygwin not required. You can get binaries for Gtk+2, with a 
nice installer to boot. The only thing I had to do was add to the win32 
PATH environment variable the location of the Gtk+2 DLLs.

CLisp also comes with a nice installer.

I actually have Vasilis's original smooth-running distro up in CVS in 
the Cells-gtk repository, under "clisp-cgtk" or something. But my 
current task is to figure out how I screwed things up to break it. 
Meaning I did something to Cells or utils-kt such that code which worked 
for me (Vasilis's) now breaks. Typical. But CLisp is not my environment 
so figuring this out will take a few hours.

Then I will do up some proper install instructions -- damn, maybe I 
should learn one of the installer packages?

man, it would be great if some Lisp noob happened to know that and 
wanted to start their Lisp career by making such a contrib to a Lisp 
open source project. <hint> :)

kenny


-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <XMotd.55788$QJ3.41198@newssvr21.news.prodigy.com>
GP lisper wrote:
> On Mon, 06 Dec 2004 00:56:13 +0000, <············@cenderis.demon.co.uk> wrote:
> 
>>Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> writes:
>>
>>[...]
>>
>>
>>>"Many widgets, including scrollbars, menus, and the button family, are
>>>implemented with native platform widgets. Others, such as entries and
>>>texts, have been modified to emulate native look and feel."
>>
>>I guess to some extent it's a question of personal taste: at least one
>>Mac person has told me that Tk's not native enough for them, and that
>>they didn't much like it on Windows either.
> 
> 
> 
> I'm still chuckling over the "native widgets" idea.  Why the stuff
> produced under a delivery schedule should be deemed superior is beyond
> me.  It's like saying that a painting not done in the style of 'Artist
> X' is no good.

If you can do a novel GUI that users want to use, more power to you. 
Most of the time, most people can't. On the Mac platform, trying to do 
it is usually a foolish act of hubris.
From: Ray Dillinger
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <TNztd.10092$_3.118178@typhoon.sonic.net>
GP lisper wrote:

> I'm still chuckling over the "native widgets" idea.  Why the stuff
> produced under a delivery schedule should be deemed superior is beyond
> me.  It's like saying that a painting not done in the style of 'Artist
> X' is no good.

If you think you can do better, go for it.  But first, make a list
of all the things that the widgets you're trying to replace do.

It's going to be a long list, by the time you include keyboard 
shortcuts, drag actions, focus rules, selection methods, etc,
etc, etc.  And for every bit of that functionality, there will
be users (like me -- I *HATE* software that makes me touch the
mouse) who absolutely rely on it, including parts you may not
think are important.

If you're willing to provide everything that your users expect,
and have it actually work the way they expect it to work, you'll
spend a very long time coding. If you don't, they won't care that
your software produces correct answers; for almost anything, there
will be another program that produces correct answers and has an
interface that works the way they expect it to work.

Heck, I'd be into some changes.  I'd adore an application that
opened with, say, a pentagonal window instead of a square one,
and menu items along the left edge instead of the top, or used
a "panning" metaphor to access different parts of the
functionality instead of handling stuff with modal dialogs.
I'd like to see jaggedy-edged error message boxes like cartoon
sound effects.

But the current set of native widgets establishes the minimum
acceptable level of functionality - and frankly, there's a lot
of it.  It's going to take a long time coding to equal, let
alone surpass, the current native widgets. And if you want to
do something better, that's what you have to do to start with.

				Bear
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <SRDtd.67885$Vk6.31139@twister.nyc.rr.com>
Ray Dillinger wrote:
> GP lisper wrote:
> 
>> I'm still chuckling over the "native widgets" idea.  Why the stuff
>> produced under a delivery schedule should be deemed superior is beyond
>> me.  It's like saying that a painting not done in the style of 'Artist
>> X' is no good.
> 
> 
> If you think you can do better, go for it.  But first, make a list
> of all the things that the widgets you're trying to replace do.
> 
> It's going to be a long list, by the time you include keyboard 
> shortcuts, drag actions, focus rules, selection methods, etc,
> etc, etc.  And for every bit of that functionality, there will
> be users (like me -- I *HATE* software that makes me touch the
> mouse) who absolutely rely on it, including parts you may not
> think are important.
> 
> If you're willing to provide everything that your users expect,
> and have it actually work the way they expect it to work, you'll
> spend a very long time coding. If you don't, they won't care that
> your software produces correct answers; for almost anything, there
> will be another program that produces correct answers and has an
> interface that works the way they expect it to work.
> 
> Heck, I'd be into some changes.  I'd adore an application that
> opened with, say, a pentagonal window instead of a square one,
> and menu items along the left edge instead of the top, or used
> a "panning" metaphor to access different parts of the
> functionality instead of handling stuff with modal dialogs.
> I'd like to see jaggedy-edged error message boxes like cartoon
> sound effects.
> 
> But the current set of native widgets establishes the minimum
> acceptable level of functionality - and frankly, there's a lot
> of it.  It's going to take a long time coding to equal, let
> alone surpass, the current native widgets. And if you want to
> do something better, that's what you have to do to start with.

This is all very plausible, but wrong. :)

First of all, for God's sake, please do not make it sound as if 
programming native widgets is in any way, shape, or form easy. For 
example, you still have to set up key commands as mousing alternatives.

Second, please do not suggest that using a predefined GUI framework 
which automates things like key equivalencies is some kind of free 
lunch. First you have to learn the damn thing, and then you have to work 
around it when you want to do anything other than the pure vanilla stuff.

Third, I did scroll bars from scratch in a few days. And scroll bars are 
a nightmare, if you think about it.

Fourth, no one is suggesting everyone go out and roll their own 
portable, non-native GUI framework. Just wait for the open source fairy 
to leave one under your pillow.

Fifth, your users are doing fine on the Web and in games using 
non-standard widgets. The last I saw, people are not rejecting the web 
or games.

Six, this bit is especially off:

 > "they won't care that
 > your software produces correct answers; for almost anything, there
 > will be another program that produces correct answers and has an
 > interface that works the way they expect it to work."

There is very little good software out there, period. Produce a fine 
application using non-native widgets (but, yes, doing a decent job of 
staying close to native), and success will follow. Corrollary: if I see 
an application area is already served by a rare instance of a fine 
application, um, I better find a new application area anyway.

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: GP lisper
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <1102565573.5c15d15bb49d036e0b49d21e84682ad4@teranews>
On Wed, 08 Dec 2004 09:27:15 GMT, <····@sonic.net> wrote:
> GP lisper wrote:
>
>> I'm still chuckling over the "native widgets" idea.  Why the stuff
>> produced under a delivery schedule should be deemed superior is beyond
>> me.  It's like saying that a painting not done in the style of 'Artist
>> X' is no good.                                                      ^
>                                                                      ^
> If you think you can do better, go for it.  But first, make a list   ^
> of all the things that the widgets you're trying to replace do.      ^
                                                                       ^
                                                                       ^
All of you have supplied answers as to why a widget set exists, and    ^
missed my point that any widget set that meets ones need is fine.      ^
Throwing out a competitive set simply because it looks different -------

i.e., seems that some comments here place far too much emphasis on
'look' and not functionality or speed or slick interface, or ....

The backend is far more important than the facade.

-- 
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
From: Håkon Alstadheim
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <m03byfiwev.fsf@alstadheim.priv.no>
GP lisper <········@CloudDancer.com> writes:

> On Wed, 08 Dec 2004 09:27:15 GMT, <····@sonic.net> wrote:
>> GP lisper wrote:
>>
>>> I'm still chuckling over the "native widgets" idea.  Why the stuff
>>> produced under a delivery schedule should be deemed superior is beyond
>>> me.  It's like saying that a painting not done in the style of 'Artist
>>> X' is no good.                                                      ^
>>                                                                      ^
>> If you think you can do better, go for it.  But first, make a list   ^
>> of all the things that the widgets you're trying to replace do.      ^
>                                                                        ^
>                                                                        ^
> All of you have supplied answers as to why a widget set exists, and    ^
> missed my point that any widget set that meets ones need is fine.      ^
> Throwing out a competitive set simply because it looks different -------
>

I don't think anyone disagrees, it's just that for the functionality
to be easlily accessible, it has to follow the platform standard, or
else it has to be the one app your user lives in all day, something
like a CAD program or a Layout package. To get _all_ the functionality
without using the native widgets is nigh on impossible, especially
since an OS upgrade might make something draggable or clickable that
was not in the previous release. The platform widgets lets your app
take part in the upgrade, home cooked does not.

There is also the point that on well-made human interfaces most tasks
become /subconcious/ and /fast/. Even tiny variations e.g. in timing
and responsiveness of the mouse and keyboard, or relative position of
buttons, icons and other sensitive areas (a single pixel matters!)
will make the app feel clunky. That is the one thing I miss from the
Mac, all those things you simply don't have to think about. Unless
you've been on a Mac exlusively for at least a couple of months, I
don't think you'd understand. The fluidity, the smoothness. Just
thinking about it makes the tension drain from my shoulders.

> i.e., seems that some comments here place far too much emphasis on
> 'look' and not functionality or speed or slick interface, or ....
>
> The backend is far more important than the facade.

Of course, if you are aiming for `acceptable as proof of concept' or
`get it working, we NEED this functionality NOW!', you could get by
with a lot of things. Things like Tcl/Tk are a godsend for that. If
you want to have a hope of producing a `best of breed', native widgets
or a staff in the triple digits are the only solutions. Very few
people want to choose a platform which excludes you from `best of
breed' at the outset.
-- 
H�kon Alstadheim, hjemmepappa.
From: Peter Herth
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <cp9ch0$t6i$1@newsreader2.netcologne.de>
H�kon Alstadheim wrote:

> I don't think anyone disagrees, it's just that for the functionality
> to be easlily accessible, it has to follow the platform standard, or
> else it has to be the one app your user lives in all day, something
> like a CAD program or a Layout package. To get _all_ the functionality
> without using the native widgets is nigh on impossible, especially
> since an OS upgrade might make something draggable or clickable that
> was not in the previous release. The platform widgets lets your app
> take part in the upgrade, home cooked does not
> 
> There is also the point that on well-made human interfaces most tasks
> become /subconcious/ and /fast/. Even tiny variations e.g. in timing
> and responsiveness of the mouse and keyboard, or relative position of
> buttons, icons and other sensitive areas (a single pixel matters!)
> will make the app feel clunky. That is the one thing I miss from the
> Mac, all those things you simply don't have to think about. Unless
> you've been on a Mac exlusively for at least a couple of months, I
> don't think you'd understand. The fluidity, the smoothness. Just
> thinking about it makes the tension drain from my shoulders.
> 
> 
>>i.e., seems that some comments here place far too much emphasis on
>>'look' and not functionality or speed or slick interface, or ....
>>
>>The backend is far more important than the facade.
> 
> 
> Of course, if you are aiming for `acceptable as proof of concept' or
> `get it working, we NEED this functionality NOW!', you could get by
> with a lot of things. Things like Tcl/Tk are a godsend for that. If
> you want to have a hope of producing a `best of breed', native widgets
> or a staff in the triple digits are the only solutions. Very few
> people want to choose a platform which excludes you from `best of
> breed' at the outset.

In principle, I agree with you. Using native widgets provided by a
platform is the easiest way to blend in seamlessly, as you indeed
inherit all their default behaviour for your application without
extra work. However, for non-trivial applications, you will use some
kind of "custom widgets" anyway. If you take Word for example - the
main part of the application is the text editing area, and this is
definitely not just using a widget open for all applications but is
some construct which is created for that individual application only -
using your wording "non native". And this applies for most applications.
So the crucial part of applications is custom written for that 
application and that makes the discussion moot whether it uses
"native widgets" or not. Besides as pointed out before, Tk can
use native widgets where possible. I have no recent experiences
with Tk on windows, but I can speak about TkAqua. For those
widgets which have a native counterpart, like buttons, entry
fields and most importantly for a seamless usage, the menues,
native widgets are used. So this makes a Tk application as
native as you could wish.
The Tk text widget seems not to use the "native" Mac text widget, but
it does that for a very good reason: the Tk text widget is perhaps *the*
highlight of the whole package, with abilities exceeding all text 
widgets, I have seen so far. So it is no question of native or not, if
there is no native counterpart for it. Though it were nice, if there
were a Tk widget using the native Mac text widget in a seperate class,
as it differs in functionatily from the Tk one. For other native 
widgets, like Quicktime, there exist extensions for Tk, using these I
can play any Quicktime content in a Ltk application too.

Peter


-- 
pet project: http://dawn.netcologne.de
homepage:    http://www.peter-herth.de
lisp stuff:  http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: David Steuber
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87acsncwab.fsf@david-steuber.com>
There is another side to the GUI using native widgets argument.  On OS
X, there is a tool called Interface Builder.  This lets you compose
all sorts of interface components without writing any code.  There are
APIs for Carbon and Cocoa that can read in the resulting NIB files and
generate the GUI from them.  The NIB files even specify where the
events go.

It may be that Interface Builder is a tool worth rebuilding
specifically for Lisp that creates Lisp output instead of XML.
However, that would be a lot of work.

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1
From: Jon Boone
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <m38y87qx4y.fsf@spiritus.delamancha.org>
David Steuber <·····@david-steuber.com> writes:

> There is another side to the GUI using native widgets argument.  On OS
> X, there is a tool called Interface Builder.  This lets you compose
> all sorts of interface components without writing any code.  There are
> APIs for Carbon and Cocoa that can read in the resulting NIB files and
> generate the GUI from them.  The NIB files even specify where the
> events go.
>
> It may be that Interface Builder is a tool worth rebuilding
> specifically for Lisp that creates Lisp output instead of XML.
> However, that would be a lot of work.

  LispWorks 4.4 (recently released) has added this feature in their
  IDE.  Don't know how it compares with the Apple Development Tools
  Interface Builder, as I don't have 4.4 yet.

--jon
From: Pascal Bourguignon
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87brd3ux5n.fsf@thalassa.informatimago.com>
David Steuber <·····@david-steuber.com> writes:

> There is another side to the GUI using native widgets argument.  On OS
> X, there is a tool called Interface Builder.  This lets you compose
> all sorts of interface components without writing any code.  There are
> APIs for Carbon and Cocoa that can read in the resulting NIB files and
> generate the GUI from them.  The NIB files even specify where the
> events go.
> 
> It may be that Interface Builder is a tool worth rebuilding
> specifically for Lisp that creates Lisp output instead of XML.
> However, that would be a lot of work.

The original "prototype"  of Interface Builder was written in Lisp, as
a commercial product.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
From: Hartmann Schaffer
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <OV2ud.29$2a1.166@newscontent-01.sprint.ca>
Pascal Bourguignon wrote:
> David Steuber <·····@david-steuber.com> writes:
> 
> 
>>There is another side to the GUI using native widgets argument.  On OS
>>X, there is a tool called Interface Builder.  This lets you compose
>>all sorts of interface components without writing any code.  There are
>>APIs for Carbon and Cocoa that can read in the resulting NIB files and
>>generate the GUI from them.  The NIB files even specify where the
>>events go.
>>
>>It may be that Interface Builder is a tool worth rebuilding
>>specifically for Lisp that creates Lisp output instead of XML.
>>However, that would be a lot of work.
> 
> 
> The original "prototype"  of Interface Builder was written in Lisp, as
> a commercial product.

didn't garnet have an interface builder?  this would have to be from the 
late 1980s

hs
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <g85ud.74484$Vk6.11384@twister.nyc.rr.com>
>> David Steuber <·····@david-steuber.com> writes:
>>
>>
>>> There is another side to the GUI using native widgets argument.  On OS
>>> X, there is a tool called Interface Builder.  This lets you compose
>>> all sorts of interface components without writing any code.  There are
>>> APIs for Carbon and Cocoa that can read in the resulting NIB files and
>>> generate the GUI from them.  The NIB files even specify where the
>>> events go.
>>>
>>> It may be that Interface Builder is a tool worth rebuilding
>>> specifically for Lisp that creates Lisp output instead of XML.
>>> However, that would be a lot of work.

Kenny hates interface builders. Kenny likes text files describing 
interfaces. Assuming layout widgets are available to automatically lay 
things out neatly, with all sorts of parameters such as alignment and 
spacing. So he never actually types in coordinates, he just eyeballs 
consequent layouts and tweaks them till things look pretty.

Then he can search his interface specifications with grep. Kenny loves 
the bit about nibs being in a proprietary format and locking one into 
Objective-C. He thought Redmond was the police state, not Cupertino.

And once the the GUI interface is native text source just like the rest 
of the app, the interface can be sensitive to application conditions. 
Every good GUI is sensitive to the application context.

back on the cells-gtk ranch, <whew>, Vasilis's original is working again 
out of the box, but it turns out it was because I had hacked on Cells. 
To try to make Clisp and CormanCL developers life with Cells easier, 
since those do not support progn method combo. I /thought/ I had hacked 
it in a backward-compatible way, but I guess testing would have helped. 
kenny hates testing.

the good news is that I realize this is probably why the uffi-ized 
cells-gtk had a bunch of minor faults consisting of failures to 
propagate. vasilis did a lot of propagation using the hook I broke.

OK, back to cells-gtk for the rest of us (other than CLisp). This has 
led recursively to a project to fork UFFI, which will include support 
for booleans, callbacks from C, and CLisp (eventually).

If any noobs want to play with Lisp GUI and do so with Cells-gtk instead 
of the many fine alternatives, I will be happy to help them get started. 
Just send email directly or post to cells-gtk-devel. Start here:

    http://common-lisp.net/project/cells-gtk/

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <ai5ud.40699$6q2.32188@newssvr14.news.prodigy.com>
Kenny Tilton wrote:
> 
>>> David Steuber <·····@david-steuber.com> writes:
>>>
>>>
>>>> There is another side to the GUI using native widgets argument.  On OS
>>>> X, there is a tool called Interface Builder.  This lets you compose
>>>> all sorts of interface components without writing any code.  There are
>>>> APIs for Carbon and Cocoa that can read in the resulting NIB files and
>>>> generate the GUI from them.  The NIB files even specify where the
>>>> events go.
>>>>
>>>> It may be that Interface Builder is a tool worth rebuilding
>>>> specifically for Lisp that creates Lisp output instead of XML.
>>>> However, that would be a lot of work.
> 
> 
> Kenny hates interface builders. Kenny likes text files describing 
> interfaces.

Me too, so I hope you build UI tools that succeed  in really doing the 
job on OS X. I'll be keen to use them. But I'm not holding my breath.
From: Peter Seibel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <m3pt1jlzj1.fsf@javamonkey.com>
mikel <·····@evins.net> writes:

> Kenny Tilton wrote:
>> 
>>>> David Steuber <·····@david-steuber.com> writes:
>>>>
>>>>
>>>>> There is another side to the GUI using native widgets argument.  On OS
>>>>> X, there is a tool called Interface Builder.  This lets you compose
>>>>> all sorts of interface components without writing any code.  There are
>>>>> APIs for Carbon and Cocoa that can read in the resulting NIB files and
>>>>> generate the GUI from them.  The NIB files even specify where the
>>>>> events go.
>>>>>
>>>>> It may be that Interface Builder is a tool worth rebuilding
>>>>> specifically for Lisp that creates Lisp output instead of XML.
>>>>> However, that would be a lot of work.
>> Kenny hates interface builders. Kenny likes text files describing
>> interfaces.
>
> Me too, so I hope you build UI tools that succeed  in really doing the
> job on OS X. I'll be keen to use them. But I'm not holding my breath.

For starters, is the NIB file format specified somewhere?

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <297ud.31338$zx1.22297@newssvr13.news.prodigy.com>
Peter Seibel wrote:
> mikel <·····@evins.net> writes:
> 
> 
>>Kenny Tilton wrote:
>>
>>>>>David Steuber <·····@david-steuber.com> writes:
>>>>>
>>>>>
>>>>>
>>>>>>There is another side to the GUI using native widgets argument.  On OS
>>>>>>X, there is a tool called Interface Builder.  This lets you compose
>>>>>>all sorts of interface components without writing any code.  There are
>>>>>>APIs for Carbon and Cocoa that can read in the resulting NIB files and
>>>>>>generate the GUI from them.  The NIB files even specify where the
>>>>>>events go.
>>>>>>
>>>>>>It may be that Interface Builder is a tool worth rebuilding
>>>>>>specifically for Lisp that creates Lisp output instead of XML.
>>>>>>However, that would be a lot of work.
>>>
>>>Kenny hates interface builders. Kenny likes text files describing
>>>interfaces.
>>
>>Me too, so I hope you build UI tools that succeed  in really doing the
>>job on OS X. I'll be keen to use them. But I'm not holding my breath.
> 
> 
> For starters, is the NIB file format specified somewhere?

Sure. All you have to do to see the spec is get a job with the 
appropriate group in Apple.
From: Oyvin Halfdan Thuv
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <cpc07a$2vv$1@orkan.itea.ntnu.no>
Kenny Tilton wrote:

> Kenny hates interface builders. Kenny likes text files describing 
> interfaces.

Wich probably means that Kenny is an interface builder himself. I wonder 
how he deals with that every day :)

> Assuming layout widgets are available to automatically lay 
> things out neatly, with all sorts of parameters such as alignment and 
> spacing. So he never actually types in coordinates, he just eyeballs 
> consequent layouts and tweaks them till things look pretty.

MrEdDesigner (for plt-scheme), and glade both are interfacebuilders, but 
they still use layouts. The difference from editing textfiles are that 
you can play around with it with the mouse-pointer, and look at the 
result at the same time you are constructing it. People tend to like 
things like that. Many people like that. Even Lisp programmers like it!

> OK, back to cells-gtk for the rest of us (other than CLisp). This has 
> led recursively to a project to fork UFFI, which will include support 
> for booleans, callbacks from C, and CLisp (eventually).

Out of curiosity: Why fork UFFI instead of helping the developers out, 
making it better?

And, yes, another question I'm curious about: Are c-callbacks so much 
better than using pipes (like LTk or cl-gtk)? Is it worth the extra 
complexity issues, that so far seems to only make things less portable 
between CL implementations?

-- 
�yvin
From: Julian Stecklina
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <86oeh2grd2.fsf@goldenaxe.localnet>
Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> writes:

> And, yes, another question I'm curious about: Are c-callbacks so much
> better than using pipes (like LTk or cl-gtk)? Is it worth the extra
> complexity issues, that so far seems to only make things less portable
> between CL implementations?

You do not have to write C wrappers or "servers" when you want to use
a library, if you have c-callbacks. It makes developing FFI glue a lot
easier.

Regards,
-- 
                    ____________________________
 Julian Stecklina  /  _________________________/
  ________________/  /
  \_________________/  LISP - truly beautiful
From: Kenneth Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <ktilton-7301ED.14491511122004@nycmny-nntp-rdr-03-ge1.rdc-nyc.rr.com>
In article <············@orkan.itea.ntnu.no>,
 Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> wrote:

> Kenny Tilton wrote:
> 
> > Kenny hates interface builders. Kenny likes text files describing 
> > interfaces.
> 
> Wich probably means that Kenny is an interface builder himself. I wonder 
> how he deals with that every day :)
> 
> > Assuming layout widgets are available to automatically lay 
> > things out neatly, with all sorts of parameters such as alignment and 
> > spacing. So he never actually types in coordinates, he just eyeballs 
> > consequent layouts and tweaks them till things look pretty.
> 
> MrEdDesigner (for plt-scheme), and glade both are interfacebuilders, but 
> they still use layouts. The difference from editing textfiles are that 
> you can play around with it with the mouse-pointer, and look at the 
> result at the same time you are constructing it. People tend to like 
> things like that. Many people like that. Even Lisp programmers like it!

Well I certainly understand that appeal of the things, i am just saying 
that, in the end, they suck, for the very specific reasons I gave, which 
went unaddressed by what you wrote, so i'll stop here.

> 
> > OK, back to cells-gtk for the rest of us (other than CLisp). This has 
> > led recursively to a project to fork UFFI, which will include support 
> > for booleans, callbacks from C, and CLisp (eventually).
> 
> Out of curiosity: Why fork UFFI instead of helping the developers out, 
> making it better?

Actually, that is a false choice. Anything I add will be freely 
available to UFFI for inclusion there. Oh, I remember, you want /me/ to 
do it. Anyway...

The decision to fork was made after consultation with Mr. Rosenberg. I 
am loathe to speak for the man, but he seemed happy to see the major 
changes I and others have in mind handled as a fork. UFFI is both vital 
to his work (which is keeping him too busy to fuss with an UFFI 
upheaval) and relatively more fragile (his word, meaning only that any 
change to it can easily upset one of the many FFIs supported, forcing 
retesting across many platforms). 

Oh, and UFFI is fine the way it is for his work. 

Oh, and Mr. Rosenberg envisions some necessary enhancements as best 
being made in a way not backwards compatible. ie, even if this were 
still a UFFI project it would have to be a non-compatible fork.

Put it all together, and what do you get? A fork. :)

> 
> And, yes, another question I'm curious about: Are c-callbacks so much 
> better than using pipes (like LTk or cl-gtk)? Is it worth the extra 
> complexity issues, that so far seems to only make things less portable 
> between CL implementations?

I do not have strong feelings either way, to be honest. The pipes are 
slower, but I do not know if the difference is significant in real-world 
use. I do not know what you mean about complexity. I would not call the 
hassles of dealing with FFI a complexity thing so much as an 
aggravation. :) And having extended Ltk quite a bit in Celtic, I hope 
you are not painting pipes as a free lunch. :) In fact, i would rather 
mess with FFI than message synchronization. But YMMV.

The big thing might be this: the FFI aggravation is a one-time thing 
which only the maintainers have to muddle through once. The performance 
drag of using pipes is forever and for all users. But again I do not 
know if the drag is significant, which is why I am indifferent on the 
issue pending determination of that.

kenny
From: Juan Jose Garcia Ripoll
Subject: Forking UFFI?
Date: 
Message-ID: <31tjnoF3ds4tnU1@individual.net>
Kenny Tilton wrote:
> OK, back to cells-gtk for the rest of us (other than CLisp). This has 
> led recursively to a project to fork UFFI, which will include support 
> for booleans, callbacks from C, and CLisp (eventually).

While forking can be interesting for some stuff (for instance, different 
lisp implementations with different functionality, change in design of 
libraries, etc), I see UFFI more than just a library, and closer to a 
defacto standard.

For instance, ECL (http://ecls.sf.net) builds its FFI using the UFFI 
specification. There's no need for wrappers or a UFFI library at all 
because the functionality that can be implemented with our means is 
there (Thanks to a great extent to Michael Goffioul's work)

If you go on and extend the UFFI library, I would ask you to do it in a 
responsible way, not breaking the interface that is already designed, 
and document your extensions in a similar way to what the UFFI project 
does, with views on a possible merge afterwards.

Regards,

Juanjo
From: Kenny Tilton
Subject: Re: Forking UFFI?
Date: 
Message-ID: <t%Gud.80946$Vk6.71501@twister.nyc.rr.com>
Juan Jose Garcia Ripoll wrote:

> Kenny Tilton wrote:
> 
>> OK, back to cells-gtk for the rest of us (other than CLisp). This has 
>> led recursively to a project to fork UFFI, which will include support 
>> for booleans, callbacks from C, and CLisp (eventually).
> 
> 
> While forking can be interesting for some stuff (for instance, different 
> lisp implementations with different functionality, change in design of 
> libraries, etc), I see UFFI more than just a library, and closer to a 
> defacto standard.
> 
> For instance, ECL (http://ecls.sf.net) builds its FFI using the UFFI 
> specification. There's no need for wrappers or a UFFI library at all 
> because the functionality that can be implemented with our means is 
> there (Thanks to a great extent to Michael Goffioul's work)
> 
> If you go on and extend the UFFI library, I would ask you to do it in a 
> responsible way, not breaking the interface that is already designed, 
> and document your extensions in a similar way to what the UFFI project 
> does, with views on a possible merge afterwards.

You make very good sense, but things are not quite the way you describe 
them. the fork decision was made in consultation with the UFFI 
maintainer, Mr. Rosenberg. See the "cells-gtk screenshots" thread later 
on for my response to oyvin.

Now, since you and Oyvin have taken the liberty of telling the Open 
source fairy what to do, I have in return assigned the two of you to 
porting all the extensions I do back to UFFI. :) Since this is so 
important to you, i assume you accept. Welcome aboard!

The first thing to do is join the cells-devel list so you can track any 
work i do. If I actually get anywhere -- always a big question -- i will 
start a dedicated common-lisp.net project for the new FF project, but 
until then I have just pulled it into one of the Cello packages in which 
I already added callbacks into Lisp from C, something UFFI never offered 
(tho I see glimmers of it in the latest source).

In fact, you can get started right away. There is plenty to do, 
including polishing up my callback stuff to be more UFFI-ish, as well as 
extending the PDF doc to cover the callbacks. It is great having you on 
board, because I hate writing doc.

While you do that, Oyvin can be adding CLisp to the UFFI code. Thanks so 
much for volunteering to pitch in. I will be watching for your 
cells-devel signup.

:)

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Oyvin Halfdan Thuv
Subject: Re: Forking UFFI?
Date: 
Message-ID: <cpfgqm$4r4$1@orkan.itea.ntnu.no>
Kenny Tilton wrote:

> Now, since you and Oyvin have taken the liberty of telling the Open 
> source fairy what to do,

??

Honestly, I seriously didn't want to offend you. I was just wondering 
what would be the better approach for implementation independence for a 
GUI-library. The reasons for forking a quite decent working, 
implementation independent project ought to be good. So I really was 
wondering. The answer was informative though. Thanks.

> While you do that, Oyvin can be adding CLisp to the UFFI code. Thanks so 
> much for volunteering to pitch in.

That would indeed be useful, except that I probably would do more damage 
than constructive work there :/

 > :)
 >
 > kenny

Now, you do have a sweet smile, don't you ;)

-- 
�yvin
From: Kenneth Tilton
Subject: Re: Forking UFFI?
Date: 
Message-ID: <ktilton-DFEAF8.14465211122004@nycmny-nntp-rdr-03-ge1.rdc-nyc.rr.com>
In article <············@orkan.itea.ntnu.no>,
 Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> wrote:

> Kenny Tilton wrote:
> 
> > Now, since you and Oyvin have taken the liberty of telling the Open 
> > source fairy what to do,
> 
> ??
> 
> Honestly, I seriously didn't want to offend you. I was just wondering 

Oh, come off it. Here is what you wrote:

> > Out of curiosity: Why fork UFFI instead of helping the developers out, 
> > making it better?

That is what we call a non-questioning question, since you jumped from 
curiosity to accusing me of not helping others before waiting for an 
answer. 


> what would be the better approach for implementation independence for a 
> GUI-library. The reasons for forking a quite decent working, 
> implementation independent project ought to be good. So I really was 
> wondering. The answer was informative though. Thanks.

Answer? I got back from a day trip to find it unsent. I thought. Anyway, 
it will be (re?)posted shortly.
> 
> > While you do that, Oyvin can be adding CLisp to the UFFI code. Thanks so 
> > much for volunteering to pitch in.
> 
> That would indeed be useful, except that I probably would do more damage 
> than constructive work there :/

Nice try. You must know C. if not, there are books you can buy. I want 
your ass in a chair at 9am Monday morning working on the UFFI code. 

:)

kenny
From: Chris Capel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <10rpotsft9s8uac@corp.supernews.com>
Kenny Tilton wrote:

> 
>>> David Steuber <·····@david-steuber.com> writes:
>>>
>>>
>>>> There is another side to the GUI using native widgets argument.  On OS
>>>> X, there is a tool called Interface Builder.  This lets you compose
>>>> all sorts of interface components without writing any code.  There are
>>>> APIs for Carbon and Cocoa that can read in the resulting NIB files and
>>>> generate the GUI from them.  The NIB files even specify where the
>>>> events go.
>>>>
>>>> It may be that Interface Builder is a tool worth rebuilding
>>>> specifically for Lisp that creates Lisp output instead of XML.
>>>> However, that would be a lot of work.
> 
> Kenny hates interface builders. Kenny likes text files describing
> interfaces. Assuming layout widgets are available to automatically lay
> things out neatly, with all sorts of parameters such as alignment and
> spacing. So he never actually types in coordinates, he just eyeballs
> consequent layouts and tweaks them till things look pretty.

I agree that defining layouts in text is a good thing. One aspect I didn't
see you mention, though, is that when you have a lot of repetitive
controls, you can lay them out using functions or macros where an interface
builder would give you a very similar five lines creating a widget about a
thousand times.

I've been playing around with ltk, and I like that aspect of it a lot
compared to something like C#. (Even in C# I do some interface building in
code here and there, but it's painful as the compile-run-debug cycle is
several seconds longer.) But how do you deal with the issue of changing one
little parameter or coordinate just a little bit in code and then updating
the window with that new value? When I had to do it I just closed the
window and recreated it with the new function, but it'd be neat to be able
to just re-evaluate that one form in my layout definition and have it
update the current window. That'd make it almost as quick as an interface
builder. :-)

So, for instance, if you have this (using absolute layouts--I'm addicted):

(form :title "Hello, world!"
      :children (button :symbol test-button
                        :text "Push me."
                        :position (10 10)
                        :size (150 30)))

Then you evaluate it, and up pops your little form. Now, you want to move
the button over just a few pixels, so what'd be neat is to be able to just
re-evaluate that one (button ...) form and have the button schootch over
live in your window.

Chris Capel
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <e17vd.24171$Yh2.10631497@twister.nyc.rr.com>
Chris Capel wrote:
> Kenny Tilton wrote:
> 
> 
>>>>David Steuber <·····@david-steuber.com> writes:
>>>>
>>>>
>>>>
>>>>>There is another side to the GUI using native widgets argument.  On OS
>>>>>X, there is a tool called Interface Builder.  This lets you compose
>>>>>all sorts of interface components without writing any code.  There are
>>>>>APIs for Carbon and Cocoa that can read in the resulting NIB files and
>>>>>generate the GUI from them.  The NIB files even specify where the
>>>>>events go.
>>>>>
>>>>>It may be that Interface Builder is a tool worth rebuilding
>>>>>specifically for Lisp that creates Lisp output instead of XML.
>>>>>However, that would be a lot of work.
>>
>>Kenny hates interface builders. Kenny likes text files describing
>>interfaces. Assuming layout widgets are available to automatically lay
>>things out neatly, with all sorts of parameters such as alignment and
>>spacing. So he never actually types in coordinates, he just eyeballs
>>consequent layouts and tweaks them till things look pretty.
> 
> 
> I agree that defining layouts in text is a good thing. One aspect I didn't
> see you mention, though, is that when you have a lot of repetitive
> controls, you can lay them out using functions or macros where an interface
> builder would give you a very similar five lines creating a widget about a
> thousand times.

Good point. Mind you, I am not conversant with how fancy interface 
builders have become. I imagine they let one create reusable, compound 
components, but would they be parameterizable like a function or macro? 
And then the code has to drive that somehow. Unlikely that could work, 
now that I think about it.

Which reminds me of another problem with interface builders: some of the 
action ends up in the code, some of it ends up in the builder definition 
of the interface. When the interface gets sensitive to the application 
context the ideal separation of model and view breaks down, and then the 
separation of interface from application becomes bane, not boon.

> 
> I've been playing around with ltk, and I like that aspect of it a lot
> compared to something like C#. (Even in C# I do some interface building in
> code here and there, but it's painful as the compile-run-debug cycle is
> several seconds longer.) But how do you deal with the issue of changing one
> little parameter or coordinate just a little bit in code and then updating
> the window with that new value? When I had to do it I just closed the
> window and recreated it with the new function, but it'd be neat to be able
> to just re-evaluate that one form in my layout definition and have it
> update the current window. That'd make it almost as quick as an interface
> builder. :-)
> 
> So, for instance, if you have this (using absolute layouts--I'm addicted):
> 
> (form :title "Hello, world!"
>       :children (button :symbol test-button
>                         :text "Push me."
>                         :position (10 10)
>                         :size (150 30)))
> 
> Then you evaluate it, and up pops your little form. Now, you want to move
> the button over just a few pixels, so what'd be neat is to be able to just
> re-evaluate that one (button ...) form and have the button schootch over
> live in your window.

Thank god we have a dynamic language and do not need that. :) I suppose 
it could be made to work if the above expands into a class definition 
and then one specializes update-instance-for-redefined-class (?). Or in 
a functional setting you could make herculean efforts to code up 
"ensure-" vs "make-instance" and then copy from the result of a fresh 
function call to the existing widget instances.

My experience with Cells, however, has been that I fell into what I call 
instance-oriented programming. Rules for a slot are specified at 
make-instance time, so different instances of the same class can (and 
normally do) have different rules for the same slot. This makes classes 
more reusable simply because they are more customizable at make-instance 
time than is possible when only literals are specified for parametric 
slots (such as "justification", which could be :left, :right, or :center).

And with classes no longer being so fully determinative of instances, 
there is little chance an automatic method could update existing 
instances after arbitrary code changes.

Which is why I am happy I am using a language which encourages me to 
work incrementally.

kenny


-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: James Graves
Subject: GUI layout systems
Date: 
Message-ID: <css2op$as9$1@new7.xnet.com>
BTW, did anyone ever see something like the layout used in the E
quasi-parser (see the JPanel subsection):

  http://www.skyhunter.com/marcs/ewalnut.html#SEC15

It is a sort of visual layout system using text.  I thought it was a
good idea, I don't know if it is original, or if the E creators got it
off something else.

James Graves
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <1x1ud.56755$QJ3.24237@newssvr21.news.prodigy.com>
Pascal Bourguignon wrote:
> David Steuber <·····@david-steuber.com> writes:
> 
> 
>>There is another side to the GUI using native widgets argument.  On OS
>>X, there is a tool called Interface Builder.  This lets you compose
>>all sorts of interface components without writing any code.  There are
>>APIs for Carbon and Cocoa that can read in the resulting NIB files and
>>generate the GUI from them.  The NIB files even specify where the
>>events go.
>>
>>It may be that Interface Builder is a tool worth rebuilding
>>specifically for Lisp that creates Lisp output instead of XML.
>>However, that would be a lot of work.
> 
> 
> The original "prototype"  of Interface Builder was written in Lisp, as
> a commercial product.

So what?

You're right, of course; Jean-Marie Hullot wrote it and it became part 
of the ExperCommon Lisp product. Later, he was hired by NeXT and rewrote 
it in Objective C. Nowadays it's rather incestuously bound to the OS X 
application frameworks; it builds Objective C objects that are archived 
to ".nib" files whose format i not published (but which is based on the 
Objective C object archiving code). Various parameters defined by the 
Apple Human Interface Guidelines are built into Interfaace Builder (for 
example, thin blue guide lines appear when you drag widgets around, to 
show you where you are supposed to put them, and when you let go of a 
widget, InterfaceBulder nudges its position to match the guide lines).

It's certainly true that it's history includes early versions written in 
and for Lisp. That doesn't really matter much anymore; what matters is 
that it embodies the standard way to construct a Mac OS X UI. If you 
were going to build OS X apps in Lisp, it would probably be more 
sensible to read ".nib" files built with Interface Builder than you 
write your own interface builder.
From: Pascal Bourguignon
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87y8g7t45u.fsf@thalassa.informatimago.com>
mikel <·····@evins.net> writes:
> >>It may be that Interface Builder is a tool worth rebuilding
> >>specifically for Lisp that creates Lisp output instead of XML.
> >>However, that would be a lot of work.
> > The original "prototype"  of Interface Builder was written in Lisp,
> > as
> > a commercial product.
> 
> So what?

So it's a shame that Interface Builder could not promote more lisp.
One more example of a successful lisp application converted to a
lesser language.
 
In consequence, 15 years later we now have  to think about "rebuilding" it.
For some similar reasons, Linus had to "rebuild" unix twelve years ago.
An more rebuilding is done and will have to be done yet...


> You're right, of course; Jean-Marie Hullot wrote it and it became part
> of the ExperCommon Lisp product. Later, he was hired by NeXT and
> rewrote it in Objective C. Nowadays it's rather incestuously bound to
> the OS X application frameworks; it builds Objective C objects that
> are archived to ".nib" files whose format are not published (but which
> is based on the Objective C object archiving code). [...]

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <ao1ud.74289$Vk6.60415@twister.nyc.rr.com>
H�kon Alstadheim wrote:

> There is also the point that on well-made human interfaces most tasks
> become /subconcious/ and /fast/. Even tiny variations e.g. in timing
> and responsiveness of the mouse and keyboard, or relative position of
> buttons, icons and other sensitive areas (a single pixel matters!)
> will make the app feel clunky. That is the one thing I miss from the
> Mac, all those things you simply don't have to think about. Unless
> you've been on a Mac exlusively for at least a couple of months, I
> don't think you'd understand. The fluidity, the smoothness. Just
> thinking about it makes the tension drain from my shoulders.

I had been tempted to point out, and now must, that the the encomiums on 
native widgetry which most brought tears to my eyes have come from 
Mikel, who... wait for it... is really talking about the Mac! And now 
that I have been working on OS/X for, yes, more than a few weeks, I am 
reminded how elegant can elegant be. Sweet.

But then the reality is that there is a great big world out there where, 
as with hand grenades, close will be good enough. Enterprise apps used 
exclusively and heavily, games, windows, Web pages, and, as someone 
noted, even in a compliant Mac app where one wants a widget or two which 
Apple did not think of.

Let's hope that, like Lisp, the Mac soon rules the world and we all end 
up having to toe that line. But by then Cello will be faking everything 
Cocoa (Aqua? Quartz?) provides off the shelf.

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: mikel
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <GH1ud.31224$zx1.18967@newssvr13.news.prodigy.com>
Kenny Tilton wrote:
> 
> 
> H�kon Alstadheim wrote:
> 
>> There is also the point that on well-made human interfaces most tasks
>> become /subconcious/ and /fast/. Even tiny variations e.g. in timing
>> and responsiveness of the mouse and keyboard, or relative position of
>> buttons, icons and other sensitive areas (a single pixel matters!)
>> will make the app feel clunky. That is the one thing I miss from the
>> Mac, all those things you simply don't have to think about. Unless
>> you've been on a Mac exlusively for at least a couple of months, I
>> don't think you'd understand. The fluidity, the smoothness. Just
>> thinking about it makes the tension drain from my shoulders.
> 
> 
> I had been tempted to point out, and now must, that the the encomiums on 
> native widgetry which most brought tears to my eyes have come from 
> Mikel, who... wait for it... is really talking about the Mac! And now 
> that I have been working on OS/X for, yes, more than a few weeks, I am 
> reminded how elegant can elegant be. Sweet.

And as I said before, if you can really roll your own and do it better, 
more power to you. It's just that most of the time when people try to do 
that, they fail.

The standard Mac UI is very involved. Mac users take for granted that 
you are going to toe the line, and often conceive bitter hatreds of 
developers who don't. Apple itself screws it up sometimes (I say that 
speaking as someone who has been there when it happened).

If you try to roll your own, the odds are against you. That remark 
should, of course, not be construed as any discouragement to those who 
like to play long odds. Sometimes a long shot pays off big. Most of the 
time it doesn't but, hey, that's why they call it a long shot.
From: Ray Dillinger
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <L1Gud.10872$_3.125133@typhoon.sonic.net>
H�kon Alstadheim wrote:

>  To get _all_ the functionality
> without using the native widgets is nigh on impossible, especially
> since an OS upgrade might make something draggable or clickable that
> was not in the previous release. The platform widgets lets your app
> take part in the upgrade, home cooked does not.

Just a note here, but native platform widgets also allow you to
participate in "DLL hell", where an upgrade to some completely
different application can break your program by making its OS
interface behave in new, exciting and different ways.  Unfortunately,
sometimes a release or two before something becomes "draggable",
it becomes "crashable" when someone tries to drag it instead of
just ignoring the drag message.

Back during the browser wars, when new misfeatures in IE were
intentionally introduced frequently in order to entice people to
make noncompliant pages that no other browser would properly view,
I was on teams that statically linked all that crap (bypassing
the chance to "participate" in updates) just to defeat the
constant stream of new bugs and misfeatures that came out with
every new release of IE.

				Bear
From: Håkon Alstadheim
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <m0u0qvhgjb.fsf@alstadheim.priv.no>
GP lisper <········@CloudDancer.com> writes:

[snip]

> The backend is far more important than the facade.

What is facade in a GUI? Every bit matters. On a good GUI platform,
most tasks become subconscious. The timing and responsiveness of the
mouse and keyboard become important. Relative placement of sensitive
areas (a single pixel matters!). Vague hints given by color, fonts,
borders etc. are taken in, and lets you flick your wrist or hit the TAB
key the right number of times without even thinking. If your
expectations as a user is not met, even a single time, the user has to
slow down and start /thinking/, verifying that every input is
interpreted the way the user intend. The app will feel clunky and
stress-inducing. For some types of app that is fine. For others it is
simply unacceptable. By going with something like Tcl/Tk, you gain
something, but you also loose several whole segments of the market.
-- 
H�kon Alstadheim, hjemmepappa.
From: Peter Herth
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <cp9cms$a4$1@newsreader2.netcologne.de>
H�kon Alstadheim wrote:

>>The backend is far more important than the facade.
> 
> 
> What is facade in a GUI? Every bit matters. On a good GUI platform,
> most tasks become subconscious. The timing and responsiveness of the
> mouse and keyboard become important. Relative placement of sensitive
> areas (a single pixel matters!). Vague hints given by color, fonts,
> borders etc. are taken in, and lets you flick your wrist or hit the TAB
> key the right number of times without even thinking. If your
> expectations as a user is not met, even a single time, the user has to
> slow down and start /thinking/, verifying that every input is
> interpreted the way the user intend. The app will feel clunky and
> stress-inducing. For some types of app that is fine. For others it is
> simply unacceptable. By going with something like Tcl/Tk, you gain
> something, but you also loose several whole segments of the market.

Correct, to be usable with ease, all applications should adhere to
rather strict user interface guidelines. But could you please elaborate, 
what exactly prevents you using Tcl/Tk to write an application that 
feels unintuitive in the way you described?

Peter

-- 
pet project: http://dawn.netcologne.de
homepage:    http://www.peter-herth.de
lisp stuff:  http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <zJsrd.37080$Vk6.4854@twister.nyc.rr.com>
Jon Boone wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>Nothing new to announce, just terribly pleased with myself for
>>successfully doing HTML, CVS, and FTP all in the same day:
>>
>>   http://common-lisp.net/project/cells-gtk/
> 
> 
>     Is the Mac version done yet?

Boy, that is a tough one. First, GTK+2 is not yet native on the Mac, tho 
it seems it could run with X11 over there. Second, CLisp's FFI is not 
there yet on the Mac, so we would be stuck with my UFFI version and 
Lispworks or OpenMCL or something, which just got a little healthier 
with a patch from Vasilis.

Have you built GTK+2 for the Mac using X11? If so, I will ride shotgun 
on any effort to port to the Mac, but I want to get back to Cello now 
and get /that/ fully operational under os/x.

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <4Xsrd.37088$Vk6.14374@twister.nyc.rr.com>
Kenny Tilton wrote:
> 
> 
> Jon Boone wrote:
> 
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>
>>> Nothing new to announce, just terribly pleased with myself for
>>> successfully doing HTML, CVS, and FTP all in the same day:
>>>
>>>   http://common-lisp.net/project/cells-gtk/
>>
>>
>>
>>     Is the Mac version done yet?
> 
> 

PS, it ain't got Cells, but it is running under OpenMCL:

     http://common-lisp.net/project/lambda-gtk/

So clearly GTK+2 is up and running somehow on os/x. Rick identifies 
"CLisp and/or UFFI" as part of the to-do list. I say extend UFFI to 
support CLisp and kill two birds.

Anyone working on adding CLisp support to UFFI?

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Jon Boone
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <m3653ly2xx.fsf@spiritus.delamancha.org>
Kenny Tilton <·······@nyc.rr.com> writes:

> Kenny Tilton wrote:
>> Jon Boone wrote:
>> 
>>> Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>> Nothing new to announce, just terribly pleased with myself for
>>>> successfully doing HTML, CVS, and FTP all in the same day:
>>>>
>>>>   http://common-lisp.net/project/cells-gtk/
>>>
>>>
>>>
>>>     Is the Mac version done yet?
>> 
>
> PS, it ain't got Cells, but it is running under OpenMCL:
>
>      http://common-lisp.net/project/lambda-gtk/
>
> So clearly GTK+2 is up and running somehow on os/x. 

    Yeah, some folks on planet.lisp.org have been posting
  screenshots.  And there's been some discussion of it on #lisp.   

--jon
From: David Steuber
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87wtw0vclo.fsf@david-steuber.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> Jon Boone wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>Nothing new to announce, just terribly pleased with myself for
> >>successfully doing HTML, CVS, and FTP all in the same day:
> >>
> >>   http://common-lisp.net/project/cells-gtk/
> >     Is the Mac version done yet?
> 
> Boy, that is a tough one. First, GTK+2 is not yet native on the Mac,
> tho it seems it could run with X11 over there. Second, CLisp's FFI is
> not there yet on the Mac, so we would be stuck with my UFFI version

It isn't?  Nuts.

> and Lispworks or OpenMCL or something, which just got a little
> healthier with a patch from Vasilis.
> 
> Have you built GTK+2 for the Mac using X11? If so, I will ride shotgun
> on any effort to port to the Mac, but I want to get back to Cello now
> and get /that/ fully operational under os/x.

I have CLisp, Gimp2, and a few other things built from the Darwin
Ports collection.  Gimp2 uses some version of GTK, I'm not sure which,
and is running it using X11.app rather than native.  Darwin Ports
sucks down and builds dependencies similar to the way FreeBSD ports
work.  All the code is compiled from source + Darwin Ports patches.

In theory, I have the GTK libs that I would need.  If FFI won't work
on my Mac, then I guess I'm foiled at that point.  I thought of a
possible project (I don't know how big it is) this morning where
lambda-gtk and CLisp (or any other Lisp that can work with it) would
be a reasonable target for a x-platform application.

I haven't tried hooking up CLisp to SLIME on my Mac.  I've been using
OpenMCL.  I've also used SBCL.  I'm not sure what the best way to
develop using CLisp is.

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <toIrd.18413$Yh2.7014709@twister.nyc.rr.com>
David Steuber wrote:

> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>Jon Boone wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>>Nothing new to announce, just terribly pleased with myself for
>>>>successfully doing HTML, CVS, and FTP all in the same day:
>>>>
>>>>  http://common-lisp.net/project/cells-gtk/
>>>
>>>    Is the Mac version done yet?
>>
>>Boy, that is a tough one. First, GTK+2 is not yet native on the Mac,
>>tho it seems it could run with X11 over there. Second, CLisp's FFI is
>>not there yet on the Mac, so we would be stuck with my UFFI version
> 
> 
> It isn't?  Nuts.
> 
> 
>>and Lispworks or OpenMCL or something, which just got a little
>>healthier with a patch from Vasilis.
>>
>>Have you built GTK+2 for the Mac using X11? If so, I will ride shotgun
>>on any effort to port to the Mac, but I want to get back to Cello now
>>and get /that/ fully operational under os/x.
> 
> 
> I have CLisp, Gimp2, and a few other things built from the Darwin
> Ports collection.  Gimp2 uses some version of GTK, I'm not sure which,
> and is running it using X11.app rather than native.  Darwin Ports
> sucks down and builds dependencies similar to the way FreeBSD ports
> work.  All the code is compiled from source + Darwin Ports patches.
> 
> In theory, I have the GTK libs that I would need.  If FFI won't work
> on my Mac, then I guess I'm foiled at that point.  I thought of a
> possible project (I don't know how big it is) this morning where
> lambda-gtk and CLisp (or any other Lisp that can work with it) would
> be a reasonable target for a x-platform application.

You lost me. If any Lisp will do, why does CLisp's FFI not being 
available on OS X stop you? Or is it that the lambda-gtk FFI work is not 
UFFI-ized?

Well, (a) CLisp is looking for help porting the FFI (I demurred, since 
for now I am still using Glut for portability and am working on 
cells-gtk just enough to see if it can be made portable then I want to 
get back to Cello.) (b) lambda-gtk could be UFFI-ized pretty easily, 
since you have the sexpr-yFFIGEN output to work off with a clever macro 
or two. (c) cells-gtk has been largely UFFI-ized (just one ACL-specific 
left to UFFI-ize) and will be fully so perty soon since I am working on 
a Lispworks port as we speak. So... get off your duff and get to work? :)

Note to newbies from the land of C: your expertise may matter more than 
a Lisp guru's on this FFI work. Including building things like GTK+ and 
adding debugging stuff, as Frank G did when we were stumped for a while 
by OS X and Aplle's Glut. And understanding the different FFIs and their 
documentation, which are more about C than Lisp. Pick a project and dive 
in. :)

kenny


-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: David Steuber
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <87pt1spejn.fsf@david-steuber.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> You lost me. If any Lisp will do, why does CLisp's FFI not being
> available on OS X stop you? Or is it that the lambda-gtk FFI work is
> not UFFI-ized?

Mostly the latter.  I haven't even checked to see if UFFI works with
OpenMCL either.  And if I were to just use OpenMCL, I would probably
be sticking with the Carbon API.  There is still some stuff in Bosco I
don't fully understand too.

> Well, (a) CLisp is looking for help porting the FFI (I demurred, since
> for now I am still using Glut for portability and am working on
> cells-gtk just enough to see if it can be made portable then I want to
> get back to Cello.) (b) lambda-gtk could be UFFI-ized pretty easily,
> since you have the sexpr-yFFIGEN output to work off with a clever
> macro or two. (c) cells-gtk has been largely UFFI-ized (just one
> ACL-specific left to UFFI-ize) and will be fully so perty soon since I
> am working on a Lispworks port as we speak. So... get off your duff
> and get to work? :)

Regarding 'a, I suppose if I could figure out how to build CLisp from
CVS rather than using the Darwin Ports build which went and grabbed
various dependencies that might be an option.  That's a whole bunch of
other stuff to learn though and I have yet to do a non-toy Lisp
program.

Regarding 'b, I'm not yet comfortable writting macros, let alone
clever ones.

> Note to newbies from the land of C: your expertise may matter more
> than a Lisp guru's on this FFI work. Including building things like
> GTK+ and adding debugging stuff, as Frank G did when we were stumped
> for a while by OS X and Aplle's Glut. And understanding the different
> FFIs and their documentation, which are more about C than Lisp. Pick a
> project and dive in. :)

My C competency has rusted a bit over time.  And I never did learn to
write make files as I've always used IDEs with built in project
management like Borland C++ 2.0 and MS DevStudio 5.0.  Oh, and Xcode.
The only time I've even looked at ABI level stuff was when I used TASM
to write some C callable assembler for the 80386 under DOS.  I thought
perhaps CLisp took advantage of the fact that it is written in C for
the FFI.

I've previously been frightened by some SBCL code.  I still haven't
read the PPC PDF file that I downloaded from IBM that supposedly gives
out all the dirt (a file I seem to have misplaced) on PPC assembler
programming.

All excuses I know.  I'm still just trying to get comfortable with
Lisp and I am not investing all my spare time in doing so.

-- 
An ideal world is left as an excercise to the reader.
   --- Paul Graham, On Lisp 8.1
From: Marco Baringer
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <m2acsw5sin.fsf@bese.it>
Kenny Tilton <·······@nyc.rr.com> writes:

> Well, (a) CLisp is looking for help porting the FFI (I demurred, since 
> for now I am still using Glut for portability and am working on 
> cells-gtk just enough to see if it can be made portable then I want to 
> get back to Cello.) (b) lambda-gtk could be UFFI-ized pretty easily, 
> since you have the sexpr-yFFIGEN output to work off with a clever macro 
> or two. (c) cells-gtk has been largely UFFI-ized (just one ACL-specific 
> left to UFFI-ize) and will be fully so perty soon since I am working on 
> a Lispworks port as we speak. So... get off your duff and get to work? :)

regading (b), i wrote this a while ago for dealing with icu 3.0, it's
not perfect but may be a good starting point:

http://article.gmane.org/gmane.lisp.clump/436

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen
From: William Bland
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <pan.2004.12.01.22.54.22.278547@abstractnonsense.com>
On Wed, 01 Dec 2004 21:47:27 +0000, Kenny Tilton wrote:

> Nothing new to announce, just terribly pleased with myself for 
> successfully doing HTML, CVS, and FTP all in the same day:
> 
>    http://common-lisp.net/project/cells-gtk/

Bloody nice!

One day, Real Soon Now, when I have some spare cycles, I'm looking forward
to trying all of this stuff.

Cheers,
	Bill.
From: Kenny Tilton
Subject: Re: cells-gtk screen shots
Date: 
Message-ID: <JLsrd.37083$Vk6.7146@twister.nyc.rr.com>
William Bland wrote:

> On Wed, 01 Dec 2004 21:47:27 +0000, Kenny Tilton wrote:
> 
> 
>>Nothing new to announce, just terribly pleased with myself for 
>>successfully doing HTML, CVS, and FTP all in the same day:
>>
>>   http://common-lisp.net/project/cells-gtk/
> 
> 
> Bloody nice!
> 
> One day, Real Soon Now, when I have some spare cycles, I'm looking forward
> to trying all of this stuff.

meanwhile send vasilis your appreciation. i am hoping enough fan mail 
will suck him back in to finish my uffi version.

:)

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film