Common CL GUI
Kenny Tilton
Someone asked me in email what I had in mind, I thought I would answer
here to get folks' input. In no particular order:
- lightweight (as contrasted with CLIM)
- it will feature Cells prominently. Cells are simple, linear, one-way
constraints. Thus this GUI will be like Garnet in this respect.
- Win32, CLX, and for the Mac, I don't know, Carbon? CLX again? This
substrate thing is the question that always gets me, but as a rule I
want to be as close to native as possible so (1) things will go fast and
(2) so developers can jump outside the framework and use native stuff as
painlessly as possible. Mind you I often wonder if OpenGL should not be
the common substrate, making portability /much/ easier, but I would not
want to slow down 2d graphics or have trouble tapping native stuff. Just
over at Apple to check out the Cocoa-Carbon confusion and saw some
intriguing stuff about Quartz using PDF as the imaging model. After
playing with Marc's cl-pdf I had looked at the PDF doc in depth and had
the same idea. hmmm....
- while a softer goal is being able to get to native widgets seamlessly,
portability across OSes is the key objective. The plan will be to use
the native OS just to get a window, some bitmap primitives, and an event
stream. Widgets inside the window will be built from scratch. I've done
this a couple of times (under Mac OS9 and Win32) and managed to invlove
native widgets, so that could end up in there as well.
- Lisp. duh. but this is why I want as little as possible from the OS or
some window manager. I am thinking more about extending CL than about
leveraging existing stuff, which might be a quicker win in the short
run, but if the existing stuff is written in C it cannot be tweaked by
the Lisp user.
-- GPL at first since Cells is GPL and that's infectious, but I'll
either go LGPL with the whole shebang or offer mad cheap licensing to
those who don't want to GPL.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it.""
Elwood P. Dowd
Tim Bradshaw
> - while a softer goal is being able to get to native widgets
> seamlessly, portability across OSes is the key objective. The plan
> will be to use the native OS just to get a window, some bitmap
> primitives, and an event stream. Widgets inside the window will be
> built from scratch. I've done this a couple of times (under Mac OS9
> and Win32) and managed to invlove native widgets, so that could end up
> in there as well.
So long as you don't want people (end users, I mean) to use it very
much, this kind of thing is fine. If you do want people to use it
then you *must* use the native window system visual objects (widgets,
or whatever they are called in Windows (controls?)). If you don't you
have to emulate them absolutely seamlessly, which seems like really a
lot of work to no end. The kind of thing I mean by `seamless' is that
they must listen to *all* the things the native ones listen to. For
windows, if I set my preferred scrollbar width then your system has to
listen to that. If the native window system supports a way of
completely changing the appearance of some component, then your
version of that component needs to do the same thing.
One of the things that hurts X-based systems now is that there are now
several toolkits, not all of which (I think?) are Xt-based, and so not
all of which work the same way at all and listen to the same resources
&c &c. Windows (and, I guess, the mac) have got this bit right, even
if the actual window system they provide is deficient.
This isn't to argue against such a thing as a hacker's tool - it might
be fine for that (I use all sorts of weird non-conformant things) -
but it won't be the Lisp GUI that takes over the world unless it talks
to native widgets.
--tim
Paul Tarvydas
> much, this kind of thing is fine. If you do want people to use it
> then you *must* use the native window system visual objects (widgets,
Seconded.
Smalltalk went through this same learning curve - you might ask
Smalltalker's what they learned, I think that they will support the above
statement.
pt
Kenny Tilton
Tim Bradshaw wrote:
> * Kenny Tilton wrote:
>
>
>>- while a softer goal is being able to get to native widgets
>>seamlessly, portability across OSes is the key objective. The plan
>>will be to use the native OS just to get a window, some bitmap
>>primitives, and an event stream. Widgets inside the window will be
>>built from scratch. I've done this a couple of times (under Mac OS9
>>and Win32) and managed to invlove native widgets, so that could end up
>>in there as well.
>
>
> So long as you don't want people (end users, I mean) to use it very
> much, this kind of thing is fine. If you do want people to use it
> then you *must* use the native window system visual objects (widgets,...
I have lots to say on those issues you raised, but first I need a point
of information: how does Java work? Does the Java GUI mirror the host OS
GUI?
I did, btw, recently modify my win32 CL gui framework to handle the
"system color" (I think) win32 message which signals changes from the
Display control panel, and I use the actual colors by defau;t in
windows. So I do have a lot of thoughts on this. More later.
Paul Tarvydas
system around (which may partly explain why it's being grafted into most
popular high level languages).
Tk uses native widgets.
Tk uses paradigm(s) that extremely convenient for gui and graphics building.
(The paradigms match lisp better than almost any other language).
Tcl/Tk is extremely well-documented, something which is vital to acceptance.
pt
Pascal Costanza
>
> Tim Bradshaw wrote:
>
>> So long as you don't want people (end users, I mean) to use it very
>> much, this kind of thing is fine. If you do want people to use it
>> then you *must* use the native window system visual objects (widgets,...
>
> I have lots to say on those issues you raised, but first I need a point
> of information: how does Java work? Does the Java GUI mirror the host OS
> GUI?
The Java AWT framework (early JDKs) provided bridges to the native
libraries but whas ill-designed. Java Swing (current JDKs) has thrown
the baby out with the bath-water and does almost everything on its own.
I think the best API out there for Java is the SWT delivered with the
Eclipse IDE. SWT has returned to using the native libraries. I expect
SWT to have a great impact in the near future in the Java world.
Pascal
--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
Jim White
> I have lots to say on those issues you raised, but first I need a point
> of information: how does Java work? Does the Java GUI mirror the host OS
> GUI?
Java has two standard GUIs.
The low-level API is AWT and it is just a wrapper for a LCD selection of
OS widgets. Has the problem Tim described which is that it fails by not
providing full access to the OS methods/events.
The high-level API is Swing. It mirrors the host OS GUI through
pluggable Look & Feel (plus it has a "Java" LAF). That has largely been
a failure because it takes a huge amount of work to duplicate the
various LAFs and they never exactly match.
The new API on the block which is gaining momentum and shows real
promise of solving Java's GUI problem at last is called SWT from IBM's
Eclipse project. It's structure is probably instructive for this
discussion too. SWT, in contrast to typical AWT implementations (which
usually use C to map to AWT's "toolkit peer" API), uses Java to
implement all of the GUI code over the OS API.
So the key concept there is to basically use FFI to interface to the OS
GUI and then implement the CL GUI API in CL. That way the OS-specific
methods and events are accessible to application code that isn't happy
with the LCD API.
Jim
Carl Shapiro
> I have lots to say on those issues you raised, but first I need a
> point of information: how does Java work? Does the Java GUI mirror the
> host OS GUI?
No. Java uses its own incredibly losing facsimiles of various native
widgets. Nothing would stop you from calling down to the truly native
interface primitives but that wouldn't be a 100% "Pure Java" solution.
Christopher Browne
> One of the things that hurts X-based systems now is that there are
> now several toolkits, not all of which (I think?) are Xt-based, and
> so not all of which work the same way at all and listen to the same
> resources &c &c. Windows (and, I guess, the mac) have got this bit
> right, even if the actual window system they provide is deficient.
That's assuming that Xt is the right "lowest common denominator." And
it is by no means obvious that that is actually the case.
People want a whopping lot more than Xt resources provide; they want
the eye candy of "themes," common widgets, and all sorts of such stuff
that Xt never tried to offer.
What is unfortunate is that nothing has been /so/ clearly better than
its competitors as to lead to some X toolkit to become effectively
dominant. The toolkits that have gotten "political" dominance, like
Motif, have been pretty repellant in other ways. And the Gtk-vs-Qt
thing of late basically demonstrates that if we have learned anything
about GUIs over the last dozen years, it is that it is unrealistic to
characterize /anything/ as being "the best." People love and despise
both for an assorted set of reasons.
Actually, Java is probably better to point to, as it has attracted
three major GUI bindings:
- AWT, which, by keeping to "LCD," is fast and relatively efficient,
but unacceptable due to being pretty ugly and pretty dated and because
it is less functional than people will accept;
- Swing provides a "portable, highly functional" system by doing all the
GUI work in semi-interpreted Java. It's pretty, it's "themable," and
it does 'everything,' but it chews memory and CPU;
- IBM has SWT, which melds the approaches, defining a bigger LCD,
implementing what it can natively, and then writing the missing
bits in Java.
The notion of this leading to difficult choices should come as no
shock. The vast number of /differing/ GUIs strongly suggests that
there's no One True GUI to be found, whatever Microsoft would have us
believe...
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://cbbrowne.com/info/linuxdistributions.html
PURITAS NECESSE EST -- DON'T DO RANDOM BINDINGS.
Arthur Lemmens
Kenny Tilton wrote:
> -- GPL at first since Cells is GPL and that's infectious, but I'll
> either go LGPL with the whole shebang or offer mad cheap licensing
The LGPL makes it impossible for programmers who use commercial Lisp
compilers to distribute programs that use your library. Here's the
relevant quote from section 6 of the LGPL:
For an executable, the required form of the "work that use the
Library" must include any data and utility programs needed for
reproducting the executable from it.
I'm not a lawyer, but I think this requires that you include the
compiler with your executable. You can't do that when the compiler
can't be distributed freely.
To fix this, you need something like Franz' "Preamble to the Gnu Lesser
General Public License" (http://opensource.franz.com/preamble.html).
I would have started using (and contributing to) McClim a long time
ago if it had a more liberal license than LGPL.
Arthur Lemmens
Michael D. Kersey
> I am planning to get to work at last on a common CL gui framework.
You might consider XPCE written by Jan Wielemaker and Anjo Anjewierden
at
http://www.swi.psy.uva.nl/projects/xpce/
XPCE has been successfully interfaced to various Prologs (the first
among them being SWI-Prolog) and various lisps, IIRC Lucid Common Lisp
and Harlequin Common Lisp and LispWorks - an old URL referencing this
fact is at http://www.hio.hen.nl/faq/xpce.html
XPCE runs on most platforms.
Good Luck,
Michael D. Kersey
Wade Humeniuk
"Kenny Tilton" <kti...@nyc.rr.com> wrote in message news:3DC55242...@nyc.rr.com...
> I am planning to get to work at last on a common CL gui framework.
> Someone asked me in email what I had in mind, I thought I would answer
> here to get folks' input. In no particular order:
Whoa, looks like you have some time on your hands. Here is a
little food for thought.
Since Digitool has probably put in much effort to interface MCL to
the new Mac OSX whatever interface, this implies they have
a new CL interface to the system. Maybe you would like to look at
the interface they have developed and use it for a cross platform
definition? I assume the OSX GUI can do anything needed of a
modern GUI.
From the past I have heard laments about the demise of NeWs and
how a great UI tool it was. Maybe a new variant of NeWs, CL-NeWs
might be the way to go? Maybe in PDF (doesn't the Mac do that now?).
Strike a new CL committe to hash out a new UI. I have lots of talk about
DUIM on this group, maybe thats the way to go? Or like other posts here
maybe an interface based on IBM's SWT. Or maybe CLIM just needs a
power up and polishing.
As it being Lightweight, I do not think that is possible. Nice motherhood issue.
--
Wade
(format t "Email: ~A"
(map 'string
'code-char
'(119 104 117 109 101 110 105 117 64
116 101 108 117 115 46 110 101 116)))
Kenny Tilton
I always thought of the LGPL as precisely an attempt to make a
non-infectious GPL, but I guess Franz picked something up there about
how the LGPL and Lisp don't mix well.
Thx for the heads-up.
Hannah Schroeter
Kenny Tilton <kti...@nyc.rr.com> wrote:
>[...]
>I always thought of the LGPL as precisely an attempt to make a
>non-infectious GPL, but I guess Franz picked something up there about
>how the LGPL and Lisp don't mix well.
The LGPL works ok for C, for some values of ok (still too much legalese
compared to other licences with similar intent, if the header files
contain too much significant stuff, your code is still infected, ...),
but even begins not to work for C++ (inline functions, template
expansions, where the "merely linked to" exception that distinguishes
LGPL from GPL doesn't work any more). So I don't like LGPL all too much
more than the GPL.
Kind regards,
Hannah.
Kenny Tilton
Wade Humeniuk wrote:
> "Kenny Tilton" <kti...@nyc.rr.com> wrote in message news:3DC55242...@nyc.rr.com...
>
>>I am planning to get to work at last on a common CL gui framework.
>>Someone asked me in email what I had in mind, I thought I would answer
>>here to get folks' input. In no particular order:
>
>
> Whoa, looks like you have some time on your hands.
<heh-heh> I'll try to keep it simple, plus I have already done this
under win32 and classic mac, so there is a lot of code to rip off.
> Here is a
> little food for thought.
>
> Since Digitool has probably put in much effort to interface MCL to
> the new Mac OSX whatever interface, this implies they have
> a new CL interface to the system. Maybe you would like to look at
> the interface they have developed and use it for a cross platform
> definition? I assume the OSX GUI can do anything needed of a
> modern GUI.
Well, MCL was my first go at this. On the Mac I did use native widgets,
but under win32 the native gui concept of every widget being a window
was a pain. i got it to work with my stuff, but I hated it and yanked
it. that code is still around somewhere, tho.
The frameworks I have built on cells are pretty simple (and powerful),
so I will keep that. How much the OS can do for me... well, as much as
possible for the obvious benefits, but if I run into conflicts with
stuff like "every button is a window", something will have to give and
it won't be universality.
>
> From the past I have heard laments about the demise of NeWs and
> how a great UI tool it was. Maybe a new variant of NeWs, CL-NeWs
> might be the way to go?
not having much googling up "news". :) got a link?
> Maybe in PDF (doesn't the Mac do that now?).
YEp. I just was over there reading up on Quartz:
" Everything you see on screen is the result of millions upon millions
of calculations by Quartz, the revolutionary composited windowing system
in Mac OS X that uses the Portable Document Format (PDF) as the basis of
its imaging model."
I had been wondering if something like that was doable after playing
with cl-pdf and staring at the pdf doc from adobe. But then I guess I
would have to write a PDF imaging engine to draw into a window. /That/
would be a project.
And if I read right, they are all-OpenGL-all-the-time. Not sure on that.
>
> Strike a new CL committe to hash out a new UI.
Well, I should be able to package up what I have faster than a committe
could agree on when to hold the first meeting <g>, so I may as well
soldier on. Maybe a primitive working GUI will help focus debate.
>
> As it being Lightweight, I do not think that is possible.
Got two of 'em right here. :) Used in attractive and powerful apps, both
Mac OS9 and Win32. A quick look at the clx api gives me hope that will
fall into place nicely.
And reading that Quartz bit just now has me again wondering if OpenGL is
not the way to go-- I mean, look at its name!! :) That would make the CL
bit even lighter, and make portability even greater. But then I do have
some more work because my existing code is win32 GDT and Mac QuickDraw
(OS9).
I think the key is not to get caught up in over-design up front. Just
get something out there in open source which folks can take in any
direction they want, including rolling their own framework atop a kernel
event stream and imaging layer.
Kenny Tilton
Tim Bradshaw wrote:
> * Kenny Tilton wrote:
>
>
>>- while a softer goal is being able to get to native widgets
>>seamlessly, portability across OSes is the key objective. The plan
>>will be to use the native OS just to get a window, some bitmap
>>primitives, and an event stream. Widgets inside the window will be
>>built from scratch. I've done this a couple of times (under Mac OS9
>>and Win32) and managed to invlove native widgets, so that could end up
>>in there as well.
>
>
> So long as you don't want people (end users, I mean) to use it very
> much, this kind of thing is fine.
My humblest goal is to be able to have GUI examples in my Cells distro.
My greater objective is to distribute educational software on both
Windows and Mac, developed just once. The Ultimate objective of
providing a universal CL gui would be nice, but there I expect the seams
to start to show.
> If you do want people to use it
> then you *must* use the native window system visual objects (widgets,
> or whatever they are called in Windows (controls?)). If you don't you
> have to emulate them absolutely seamlessly, which seems like really a
> lot of work to no end.
I started on the mac/quickdraw, and there I did use native widgets. I
reluctantly gave up on those on win32 because of the
every-button-is-a-window thing. I got it to work, but hated it. Then I
found i could recreate the widget (a tab view) in a day. scrollbars took
a day (then two days to rewrite from scratch <g>).
so i am totally down for the native thing. but a little voice tells me
not to stress over that now, just get a universal platform out there and
then see where things lead. the frameworks I cook up are pretty
flexible, so nothing would stop others from tossing in thinly wrapped
native widgets (the way I did it) and dealing with consequent x-platform
incompatibilites on their own dime.
> The kind of thing I mean by `seamless' is that
> they must listen to *all* the things the native ones listen to. For
> windows, if I set my preferred scrollbar width then your system has to
> listen to that. If the native window system supports a way of
> completely changing the appearance of some component, then your
> version of that component needs to do the same thing.
I made our current app follow the win32 display control panel by
handling the "system color" or something message, so I dig the issue.
But maybe the way for me to go is just keep this thing flexible enough
that others can likewise chase after the native match, then just roll my
own universal widgets. re the latter, since I /am/ rolling my own, say,
scrollbars, it's easy to make them look like native ones.
>
> One of the things that hurts X-based systems now is that there are now
> several toolkits, not all of which (I think?) are Xt-based, and so not
> all of which work the same way at all and listen to the same resources
> &c &c. Windows (and, I guess, the mac) have got this bit right, even
> if the actual window system they provide is deficient.
>
> This isn't to argue against such a thing as a hacker's tool - it might
> be fine for that (I use all sorts of weird non-conformant things) -
> but it won't be the Lisp GUI that takes over the world unless it talks
> to native widgets.
Thx for the input. Aside from hacking, i think a universal but
not-quite-native GUI is also good for beginners, students, etc. Also
applications which do not anyway plan to look conventional, or which
will be delivered only on one system.
Kenny Tilton
Paul Tarvydas wrote:
> Tim Bradshaw wrote:
>
>
>>much, this kind of thing is fine. If you do want people to use it
>>then you *must* use the native window system visual objects (widgets,
>
>
> Seconded.
>
> Smalltalk went through this same learning curve -
That's an interesting data point.
But anyone wanting x-platform /and/ stressing over whether it looks
native is likely working at the commercial level. There a little work
($$$) can be expended to conditionalize code or maintain diff versions.
x-platform and native are contradictory unless you have some x-platform
commonality, and what I am hearing today is that even that (in the form
of the Java AWT) does not help, people still want native!
So the commercial crowd is hard to please. I better not worry about that
just yet, just get the ball rolling on at least an attractive common cl
gui.
Kenny Tilton
Pascal Costanza wrote:
> The Java AWT framework (early JDKs) provided bridges to the native
> libraries but whas ill-designed. Java Swing (current JDKs) has thrown
> the baby out with the bath-water and does almost everything on its own.
> I think the best API out there for Java is the SWT delivered with the
> Eclipse IDE. SWT has returned to using the native libraries. I expect
> SWT to have a great impact in the near future in the Java world.
>
Thx for the lead. I read up on the SWT, and it basically is how I have
done things on the Mac: go native where possible.
Someone has suggested following the Java GUI as a model... I wonder if
he was talking about eclipse?
--
Pascal Costanza
>
>
> Pascal Costanza wrote:
>
>> The Java AWT framework (early JDKs) provided bridges to the native
>> libraries but whas ill-designed. Java Swing (current JDKs) has thrown
>> the baby out with the bath-water and does almost everything on its
>> own. I think the best API out there for Java is the SWT delivered with
>> the Eclipse IDE. SWT has returned to using the native libraries. I
>> expect SWT to have a great impact in the near future in the Java world.
>>
>
> Thx for the lead. I read up on the SWT, and it basically is how I have
> done things on the Mac: go native where possible.
>
> Someone has suggested following the Java GUI as a model... I wonder if
> he was talking about eclipse?
I don't know who you are referring to, so I can't say.
BTW, if you are interested in some tidbits about the history of AWT go
and see http://c2.com/cgi/wiki?TheStoryOfAwt
Christopher Browne
> Pascal Costanza wrote:
>> The Java AWT framework (early JDKs) provided bridges to the native
>> libraries but whas ill-designed. Java Swing (current JDKs) has
>> thrown the baby out with the bath-water and does almost everything
>> on its own. I think the best API out there for Java is the SWT
>> delivered with the Eclipse IDE. SWT has returned to using the native
>> libraries. I expect SWT to have a great impact in the near future in
>> the Java world.
>>
>
> Thx for the lead. I read up on the SWT, and it basically is how I have
> done things on the Mac: go native where possible.
>
> Someone has suggested following the Java GUI as a model... I wonder if
> he was talking about eclipse?
Perhaps; I don't recall who suggested that.
SWT is probably the thing most appropriate to model, and that is what
was used to implement Eclipse. I wouldn't model Eclipse; that's not a
GUI library...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://cbbrowne.com/info/unix.html
Rules of the Evil Overlord #95. "My dungeon will have its own
qualified medical staff complete with bodyguards. That way if a
prisoner becomes sick and his cellmate tells the guard it's an
emergency, the guard will fetch a trauma team instead of opening up
the cell for a look." <http://www.eviloverlord.com/>
Timothy Moore
> Wade Humeniuk wrote:
>
> > As it being Lightweight, I do not think that is possible.
>
> Got two of 'em right here. :) Used in attractive and powerful apps,
> both Mac OS9 and Win32. A quick look at the clx api gives me hope that
> will fall into place nicely.
What does "lightweight" mean?
Tim
Greg Neumann
> Does the Java GUI mirror the host OS GUI?
It actually can; Apple did the work of making Java Swing map to its
GUI system. However, on Windows it's just an ugly facsimile.
I hear people are increasingly looking at using Mozilla's XUL
framework for building crossplatform GUIs. (So that's what they've
been spending their time on.) Maybe someone with experience can
comment on it.
http://www.xulplanet.com/tutorials/xultu/intro.html
Greg Neumann
Patrick W
> But anyone wanting x-platform /and/ stressing over whether it looks
> native is likely working at the commercial level. [...]
>
> So the commercial crowd is hard to please. I better not worry about
> that just yet, just get the ball rolling on at least an attractive
> common cl gui.
In that case, have you thought about using SDL as a low-level canvas
for a custom widget set? It's portable, and about as "lightweight" as
you could desire. I haven't looked at it very closely, but it would
seem to offer plenty of scope for designing your own widgets and event
handling mechanisms without too many built-in encumbrances. (Works
nicely with OpenGL too).
Vebjorn Ljosa
|
| Got two of 'em right here. :) Used in attractive and powerful apps,
| both Mac OS9 and Win32. A quick look at the clx api gives me hope that
| will fall into place nicely.
How about some screenshots, so we can see what the app is like?
Vebjorn
Thomas F. Burdick
> I am planning to get to work at last on a common CL gui framework.
> Someone asked me in email what I had in mind, I thought I would answer
> here to get folks' input. In no particular order:
>
> - lightweight (as contrasted with CLIM)
How about as contrasted with Garnet ;-)
> - it will feature Cells prominently. Cells are simple, linear, one-way
> constraints. Thus this GUI will be like Garnet in this respect.
Which immediately raises the question, will it be "featuring
constraints", or "constraints-based"? By analogy, I consider Java to
be a language featuring objects, versus ST or Lisp, which are objects
all the way down. Are you planning on making it essentially low-level
drawing primitives plus a constraints system? If so, then it might be
worth using over Garnet, just because of the close CLOS integration
... but it seems to me that the big thing that Garnet is missing is
native system integration, which requires striking a good balance
between Garnet's constraints-all-the-way-down approach, and having
integration where you have points you can't go below (because the
native graphics system handles them).
> - Win32, CLX, and for the Mac, I don't know, Carbon? CLX again? This
> substrate thing is the question that always gets me, but as a rule I
> want to be as close to native as possible so (1) things will go fast and
> (2) so developers can jump outside the framework and use native stuff as
> painlessly as possible. Mind you I often wonder if OpenGL should not be
> the common substrate, making portability /much/ easier, but I would not
> want to slow down 2d graphics or have trouble tapping native stuff. Just
> over at Apple to check out the Cocoa-Carbon confusion and saw some
> intriguing stuff about Quartz using PDF as the imaging model. After
> playing with Marc's cl-pdf I had looked at the PDF doc in depth and had
> the same idea. hmmm....
On the Mac, you definately do *not* want to go with CLX: I use X11
daily, but it's a little Unix/X11 world very different from the rest
of my Mac. Unless you highly value OS 9 support, you should go with
Cocoa, which is what OS X developers are generally expected to use,
and want to use.
> - while a softer goal is being able to get to native widgets seamlessly,
> portability across OSes is the key objective. The plan will be to use
> the native OS just to get a window, some bitmap primitives, and an event
> stream. Widgets inside the window will be built from scratch. I've done
> this a couple of times (under Mac OS9 and Win32) and managed to invlove
> native widgets, so that could end up in there as well.
If *I* were doing this (and I've thought some about this area, not the
least because I'm considering porting Garnet to Cocoa/OS X, so I'm not
talking out of my ass, but I'm not anything like an authority,
either), I would try to use the native windowing system to get a
window, and use the most primitive widgets it offers -- but not
primarily the bitmap primitives -- to build things on top of. I don't
have much Win32 experience, but I think this could be done well enough
to give decent native-ish look-and-feel on X11/Motif and Cocoa. Then
go ahead and build your higher-level widgets, using as many of the
primitive widgets as you can, and connecting them with constraints.
This won't give you a Really True Native Feel, but it should probably
give you something good enough that people could use it without being
asked, "why does your application *look* so funny?!?!" (which,
incidentally, I hear a lot, as I tend to deploy UIs on Garnet, Emacs,
and Squeak). Garnet's not too bad, but I only use it on X11, where it
looks kinda like Motif -- there's nothing that you could put on OS X
and Windows that would look okay on both.
> - Lisp. duh. but this is why I want as little as possible from the OS or
> some window manager. I am thinking more about extending CL than about
> leveraging existing stuff, which might be a quicker win in the short
> run, but if the existing stuff is written in C it cannot be tweaked by
> the Lisp user.
Well, only kind of "duh". Really, I think you mean "CLOS", right?
Again, contrasting to Garnet :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Takehiko Abe
> > Maybe in PDF (doesn't the Mac do that now?).
>
> YEp. I just was over there reading up on Quartz:
>
> " Everything you see on screen is the result of millions upon millions
> of calculations by Quartz, the revolutionary composited windowing system
> in Mac OS X that uses the Portable Document Format (PDF) as the basis of
> its imaging model."
Alas, 'the revolutionary composited windowing system' part of API
is not public yet AFAIK.
Takehiko Abe
> On the Mac, you definately do *not* want to go with CLX: I use X11
> daily, but it's a little Unix/X11 world very different from the rest
> of my Mac. Unless you highly value OS 9 support, you should go with
> Cocoa, which is what OS X developers are generally expected to use,
> and want to use.
Who do you think expects developers to use Cocoa?
I'm not sure I want to use it. Cocoa is an OO framework. I guess
I want to use something a bit lower in level if I want to build
a CLOS framework.
Tim Lavoie
Patrick> Kenny Tilton <kti...@nyc.rr.com> writes:
>> But anyone wanting x-platform /and/ stressing over whether it
>> looks native is likely working at the commercial level. [...]
>>
>> So the commercial crowd is hard to please. I better not worry
>> about that just yet, just get the ball rolling on at least an
>> attractive common cl gui.
Patrick> In that case, have you thought about using SDL as a
Patrick> low-level canvas for a custom widget set? It's portable,
Patrick> and about as "lightweight" as
Patrick> you could desire. I haven't looked at it very closely,
Patrick> but it would seem to offer plenty of scope for designing
Patrick> your own widgets and event
Patrick> handling mechanisms without too many built-in
Patrick> encumbrances. (Works nicely with OpenGL too).
Patrick> http://www.libsdl.org
Another possibility is wxWindows, which is a C library which then
piggybacks appropriate native widgets, so it looks like Windows under
Windows, uses GTK+ on Linux and I think works on Mac too. I've used
the wxPython bindings some, and it seems quite nice. A "wxLisp" would
certainly be a welcome addition.
Tim Bradshaw
> That's assuming that Xt is the right "lowest common denominator." And
> it is by no means obvious that that is actually the case.
Oh yes, I agree with that, I didn't mean to sound pro-Xt. But
*something* that makes the whole desktop behave like a unified whole
is a win.
--tim
Tim Bradshaw
> The low-level API is AWT and it is just a wrapper for a LCD selection
> of OS widgets. Has the problem Tim described which is that it fails
> by not providing full access to the OS methods/events.
This wasn't quite what I meant (I haven't reread what I wrote, so I
may have not said what I meant). I don't think it's necessary to
provide *full* access to native stuff, but I think that what you get
access to *should* be native stuff. If some new version of the OS
changes how scrollbars look, then my scrollbars should pick up that
change.
--tim
Tim Bradshaw
> The notion of this leading to difficult choices should come as no
> shock. The vast number of /differing/ GUIs strongly suggests that
> there's no One True GUI to be found, whatever Microsoft would have us
> believe...
Well, there may be a vast number of them, but all of them other than
the Windows one have, together, less than 10% market share on
desktops. I think someone has won this war.
--tim
Kenny Tilton
OK, but I am severely web-challenged. :) and my brave attempt to get
going on sourceforge fell on its face. hmmm... i wager i get a personal
web page with my roadrunner account... is there some easier way? NGs
don't grok pix, do they? or is that where i post in HTML?
of course, if just a few folks are interested I could do it by email.
Kenny Tilton
Thx for the lead. Looks great on the output side. I like the emphasis on
speed.
Well, I am only one person and I have this win32 and macos9 stuff
sitting here. I think what people will see is that (1) Cells are awesome
and (2) building a decent gui atop Cells was pretty easy, so they can
toss my boring gui stuff and switch to Java SWT or SDL on their own.
Me, I like the SDL because it is in C and I can just UFFI into it. Not
sure what hijinx I'd have to go thru to get to Java.
I never know when management is going to call and say "we got bucks!
back to work!", so I better get something out quick or it will be not at
all.
Kenny Tilton
I was thinking Carbon after 7 minutes of intensive study of the Apple
site. As you say, procedural vs. OO. And closer to the sand, of course.
Someone suggested wxWindows. Looks huge, but what do I do with the C++
classes? We should be building a /Lisp/ GUI. I love the idea of
leveraging existing libraries, but not where I am buying into a
framework, I just want the display capabilities (events are easy) so the
framework can be in Lisp (where Lisp users can get at it).
Michael Dingler
> Thx for the lead. Looks great on the output side. I like the emphasis
> on speed.
>
> Well, I am only one person and I have this win32 and macos9 stuff
> sitting here. I think what people will see is that (1) Cells are
> awesome and (2) building a decent gui atop Cells was pretty easy, so
> they can toss my boring gui stuff and switch to Java SWT or SDL on
> their own.
>
> Me, I like the SDL because it is in C and I can just UFFI into it. Not
> sure what hijinx I'd have to go thru to get to Java.
You might encounter some problems with SDL as it's primarily meant
for games. Multiple windows and especially transients aren't very
important for applications like this and when your context menu
doesn't reach beyond the window border in a traditional GUI app...
And you've got yet another set of libraries to install. Especially
business computers aren't very likely to have gaming libraries
already installed.
...Michael...
Kenny Tilton
Michael Dingler wrote:
> You might encounter some problems with SDL as it's primarily meant
> for games. Multiple windows and especially transients...
OK, I did notice something along those lines in my cursory review of
SDL. I think a CL gui project would have to look long and hard at any
non-native implementation substrate before adopting it. Thx for the input.
> And you've got yet another set of libraries to install.
oh, yeah. jvm and opengl i would expect to find. well, i guess an
install bundle (of a given app) could include the SDL libs if it came to
that.
Janis Dzerins
> I hear people are increasingly looking at using Mozilla's XUL
> framework for building crossplatform GUIs. (So that's what they've
> been spending their time on.)
Last time I heard about it was from that sinking XML ship...
--
Janis Dzerins
If million people say a stupid thing, it's still a stupid thing.
Kenny Tilton
From the OS I get the window, bitmap(s) and functions like BitBlt
(win32) and CopyBits (MacOS9), paint/update events, invalidate/validate
functions to trigger update events.
The GUIs I've built were simple view hierarchies with windows at the
top. every view has a slot for a model instance if needed (not on
decorative stuff). some view has the "focus". by default events meant
for the focus start at the focus and get offered in turn to parents up
the hierarchy.
views supply a paint procedure or go unpainted. event-handling is
automated somewhat by translating clicks to do-click or do-double-click,
key events to do-key, etc.
a suite of routines support dynamic changes to the view hierarchy. view
geometry is relative to one's parent, recursively so up the tree.
infinite flexibility here for thems that want it since constraints can
be arbitrary Lisp code, and redraws happen automatically.
print this out, it's the most doc i'ver ever written. :)
Kenny Tilton
Thomas F. Burdick wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>I am planning to get to work at last on a common CL gui framework.
>>Someone asked me in email what I had in mind, I thought I would answer
>>here to get folks' input. In no particular order:
>>
>>- lightweight (as contrasted with CLIM)
>
>
> How about as contrasted with Garnet ;-)
Not sure. IIRC, garnet was pretty straightforward on the GUI bit, yes?
>
>
>>- it will feature Cells prominently. Cells are simple, linear, one-way
>>constraints. Thus this GUI will be like Garnet in this respect.
>
>
> Which immediately raises the question, will it be "featuring
> constraints", or "constraints-based"?
/My/ GUI is ineluctably Cellular. But the interface-to-the-OS used by
the GUI would be stuff that would work sans Cells. I have read a little
more on SWT and I agree with one of their guiding principles, which I
will paraphrase as "Thou shalt do nothing in thine wrapper but wrap."
>
> Unless you highly value OS 9 support...
...nahhhh...
, you should go with
> Cocoa, which is what OS X developers are generally expected to use,
> and want to use.
I think I just want some primitives from carbon so I can be Lisp almost
all the way down as almost as possible.
>>- Lisp. duh.
>
>
> Well, only kind of "duh". Really, I think you mean "CLOS", right?
> Again, contrasting to Garnet :)
>
You mean emphasize the CLOS as an advantage (which I grok) or as a
limitation? If the latter, now that I have backed off the
metaclass-based approach, I wonder how well Cells and structs would get
along. I like fast. Mind you, I dig multiple inheritance big time, but
just for fun... anyway, I don't think Cells are OO-only in principle.
Wade Humeniuk
"Kenny Tilton" <kti...@nyc.rr.com> wrote in message news:3DC6CE23...@nyc.rr.com...
>
> a suite of routines support dynamic changes to the view hierarchy. view
> geometry is relative to one's parent, recursively so up the tree.
> infinite flexibility here for thems that want it since constraints can
> be arbitrary Lisp code, and redraws happen automatically.
Layouts and Interfaces like CAPI has?
Wade
Kenny Tilton
Just snuck over to the CAPI doc to see what you meant. Yes, my GUI has
row, stack, and a couple of grid classes. It is easy to roll one's own,
as well, because precisely and almost exclusively for this purpose it is
possible for a parent object (cells comes with a hierarchical Family
class) to specify constraints (cells) for child instance slots.
That's layouts. Interfaces? Well, it's all CLOS so a level of
abstraction like that (as far as I grokked it after a little perusal)
would be easy enough to layer in.
Thomas F. Burdick
> Thomas F. Burdick wrote:
>
> > Which immediately raises the question, will it be "featuring
> > constraints", or "constraints-based"?
>
> /My/ GUI is ineluctably Cellular. But the interface-to-the-OS used by
> the GUI would be stuff that would work sans Cells. I have read a little
> more on SWT and I agree with one of their guiding principles, which I
> will paraphrase as "Thou shalt do nothing in thine wrapper but wrap."
>
> > Unless you highly value OS 9 support...
>
> ...nahhhh...
>
> , you should go with
> > Cocoa, which is what OS X developers are generally expected to use,
> > and want to use.
>
> I think I just want some primitives from carbon so I can be Lisp almost
> all the way down as almost as possible.
Well, you can get the low-level primitives you'd need from Cocoa, but
it does use the PostScript imaging model, which is cool, but very
different that what you'll get on X11 or Win32. If you're going for a
GUI built entirely on bitmap primitives, I guess you might as well use
Carbon.
> >>- Lisp. duh.
> >
> > Well, only kind of "duh". Really, I think you mean "CLOS", right?
> > Again, contrasting to Garnet :)
>
> You mean emphasize the CLOS as an advantage (which I grok) or as a
> limitation?
Oh, as an advantage, as opposed to Garnet's exclusive use of KR. KR
is cool, and very useful, and I have a decent KR--CLOS bridge, but I'm
positive that's a reason it isn't and wasn't used more.
> If the latter, now that I have backed off the metaclass-based
> approach, I wonder how well Cells and structs would get along. I
> like fast. Mind you, I dig multiple inheritance big time, but just
> for fun... anyway, I don't think Cells are OO-only in principle.
Oh, certainly not, you could probably generalize it to work with
places ... but "could" and "should" are quite different here, IMO.
Thomas F. Burdick
> In article <xcv7kft...@conquest.OCF.Berkeley.EDU>, t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > On the Mac, you definately do *not* want to go with CLX: I use X11
> > daily, but it's a little Unix/X11 world very different from the rest
> > of my Mac. Unless you highly value OS 9 support, you should go with
> > Cocoa, which is what OS X developers are generally expected to use,
> > and want to use.
>
> Who do you think expects developers to use Cocoa?
Apple? From my impression, it's the preferred API.
> I'm not sure I want to use it. Cocoa is an OO framework. I guess
> I want to use something a bit lower in level if I want to build
> a CLOS framework.
Why? Yes, it's OO, but it wouldn't force you into its object model.
You could just use it as a simple binding to the PostScript image model.
Kenny Tilton
Rajappa Iyer wrote:
> I'd like to second this recommendation. Tk is a very nice toolkit
> which will lend itself very readily to CL encapsulation.
hmmm, ok, i better just do what I can with what I have on win32 and the
mac (after digitool gets me an MCL beta) and then take a look at
leveraging some existing xplatform-yet-native substrate. lots of
possibilities, it seems.
>
> Although the word Scheme is verboten in this newsgroup,...
"Right! No one is to throw a stone until I give the word."
> take a look at
> STk (Erick Gallesio's Scheme with Tk) which does a great job of
> integrating a CLOS like object system with Tk.
fascinating effort! Tk must really be something. thx for the lead.
Bruce Stephens
[...]
> > take a look at
>> STk (Erick Gallesio's Scheme with Tk) which does a great job of
>> integrating a CLOS like object system with Tk.
>
> fascinating effort! Tk must really be something. thx for the lead.
Tk is (by current standards) nothing particularly special. For the
time, it was an amazing piece of work: a nice cross-platform GUI
system, free (BSD-like license), complete with documentation and
tests. OK, I guess that's still pretty amazing, but wxwindows and gtk
both work pretty well.
The core system never became particularly portable to languages other
than Tcl, though, despite the efforts of Perl people to contribute
patches to make it so. So if you want to go the Tk route, take the
version from Perl or Python, not the original.
The successor to STk seems to be using Gtk, so that's another vote for
Gtk. I've read good things about wxwindows: it seems to me to be the
most likely to be the closest to the native look-and-feel.
Takehiko Abe
Kenny Tilton <kti...@nyc.rr.com> wrote:
> I was thinking Carbon after 7 minutes of intensive study of the Apple
> site. As you say, procedural vs. OO. And closer to the sand, of course.
Frustratingly, the state of Carbon seems far from complete. It
looks messy. Some part is modified, some removed and some are
added, all according to the Apple's idea of what we need.
Also I think the OS itself is still not mature yet. (I am not
thinking about all the GUI defects OSX has [I learned to
be patient, thanks to MicroSoft Windows.]) Apple made public
only the bottom layer [mach, bsd] and top layer [quartz,
carbon, cocoa, etc] portion of API. OSX API lacks unifying
middle layer that is 'window server'.
I have began to look at OSX and Carbon seriously just recently,
so I may be wrong. But I am prepared that porting old MCL code
to OSX is going to be a hassle. And I would not be surprised
if the coming OSX native MCL would not be as /rock/ solid as
it is in OS9 initially. I think it will take some time before
things settle down.
Takehiko Abe
> > Who do you think expects developers to use Cocoa?
>
> Apple? From my impression, it's the preferred API.
Apple did not say Cocoa is preferred as far as I know. I see
Cocoa as a development environment built on top of the OS rather
than an API. I see it more like Visual Basic in MS Windows.
> > I'm not sure I want to use it. Cocoa is an OO framework. I guess
> > I want to use something a bit lower in level if I want to build
> > a CLOS framework.
>
> Why? Yes, it's OO, but it wouldn't force you into its object model.
It is an OO framework. I think it is rather pointless to use it without
using its object model.
> You could just use it as a simple binding to the PostScript image model.
You mean 2D drawing primitives. They're used to draw application
specific 2D shapes. Using them to construct OS compliant widgets
is not feasible. I think Cocoa must depend on some lower level API
that knows how to draw widgets. I want an access to that API.
You also need a mechanism to handle UI events. If they are handled
in the Cocoa OO framework, I'm not sure how I can mesh them into my
OO framework's event handling mechanism without kludge. Again, I
want something bit lower.
But... I must say I do not know Cocoa. I am writing this largely
because I have personal gripes against Cocoa hype. Since OSX beta,
its advantages have been lauded by many people, and nobody seems to
be aware that all of the advantages have been available on classic
Mac OS for more than a decade in the form of MCL. Furthermore, this
chimera like monstrous new OS is not what I wanted and expected.
I wanted to see MCL to take over the whole OS and make Mac into a
Lisp OS.
Greg Neumann
> > I hear people are increasingly looking at using Mozilla's XUL
> > framework for building crossplatform GUIs. (So that's what they've
> > been spending their time on.)
>
> Last time I heard about it was from that sinking XML ship...
Well, take a look at implementations that use it. I don't care if it
uses XML as long as it gets the results; I can always convert from a
better format. Mozilla had a great need to write a good portable GUI
system, and it's no surprise they used a subset of a popular markup
format.
Greg Neumann
Timothy Moore
> Timothy Moore wrote:
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> >
> >>Wade Humeniuk wrote:
> >>
> >>
> >>>As it being Lightweight, I do not think that is possible.
> >>
> >>Got two of 'em right here. :) Used in attractive and powerful apps,
> >>both Mac OS9 and Win32. A quick look at the clx api gives me hope that
> >>will fall into place nicely.
> > What does "lightweight" mean?
> >
>
> From the OS I get the window, bitmap(s) and functions like BitBlt
> (win32) and CopyBits (MacOS9), paint/update events,
> invalidate/validate functions to trigger update events.
[lucid description deleted]
Thanks. So "lightweight" refers to the size of the implementation.
CLIM is certainly not lightweight by that standard, though one could
argue that it is in terms of the effort required by a programmer to
create an interface.
Tim
CY
> Thomas F. Burdick wrote:
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> >
> >
> >>I am planning to get to work at last on a common CL gui framework.
> >>Someone asked me in email what I had in mind, I thought I would answer
> >>here to get folks' input. In no particular order:
> >>
> >>- lightweight (as contrasted with CLIM)
> >
> >
> > How about as contrasted with Garnet ;-)
>
> Not sure. IIRC, garnet was pretty straightforward on the GUI bit, yes?
I guess I'm pretty late to this discussion, and this isn't strictly
relevant to the question at hand, but in case anyone didn't know
Garnet still exists, is public domain, and is available for download
at http://garnetlisp.sf.net. In my admittedly limited experience with
Garnet, it has seemed to perform fairly well on clisp once it is
compiled. Garnet has been quiet for a long time now, but there is
hope of life being breathed back into it in the future.
Just thought I'd let you know the resource is available, if it can be
of use to you.
Mario S. Mommer
smust...@hotmail.com (CY) writes:
> Kenny Tilton <kti...@nyc.rr.com> wrote
> >
> > Not sure. IIRC, garnet was pretty straightforward on the GUI bit, yes?
>
> I guess I'm pretty late to this discussion, and this isn't strictly
> relevant to the question at hand, but in case anyone didn't know
> Garnet still exists, is public domain, and is available for download
> at http://garnetlisp.sf.net. In my admittedly limited experience with
> Garnet, it has seemed to perform fairly well on clisp once it is
> compiled. Garnet has been quiet for a long time now, but there is
> hope of life being breathed back into it in the future.
>
> Just thought I'd let you know the resource is available, if it can be
> of use to you.
As a matter of fact, I think that it is a relevant comment. I'm fairly
sure that it would have a greater impact to overhaul Garnet, than to
start again from scratch to write a common CL GUI. The latter would
bear the potential to dilute even more the efforts of the community
(Just MHO).
Are there reasons why overhauling / modernizing (if that is
applicable) Garnet would not be a great idea? Even considering its
(possible) shortcommings, wouldn't it still be easier to remedy those
than to restart from scratch?
Regards,
Mario S. Mommer
P.S: And BTW, what are those Cells? Google is frustrating on that -
I'm fairly sure you don't mean Cons-Cells (which I agree are great,
btw ;-) )
Rob Warnock
+---------------
| Someone suggested wxWindows. Looks huge, but what do I do with the C++
| classes? We should be building a /Lisp/ GUI. I love the idea of
| leveraging existing libraries, but not where I am buying into a
| framework, I just want the display capabilities (events are easy) so the
| framework can be in Lisp (where Lisp users can get at it).
Look at how PLT Scheme, or rather, MrEd, the application- & GUI-builder
that runs under DrScheme does it. They use a slightly modified version
of wxWindows for their cross-platform (MS, Mac, Unix) GUI base, and IIRC
import the C++ classes fairly straightforwardly into MzScheme's single-
inheritance object system. See <URL:http://www.plt-scheme.org/software/mred/>
for more details.
Note that it does use MzScheme's thread system ("Lisp threads", as people
were calling it at ILC 2002, not "O/S threads"), so trying to copy what
they did directly would almost certainly need a Lisp implementation with
some kind of threads...
-Rob
-----
Rob Warnock, PP-ASEL-IA <rp...@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Kenny Tilton
Timothy Moore wrote:
Oops. I forgot to mention "simple, and easy to learn", which is a whole
'nother way of being lightweight. I think CLIM has a bigger learning curve
than my stuff. But my stuff is also powerful and easy when it comes to
building interfaces, in large part due to Cells.
Maybe I am confusing things for everyone. What I have done under win32 is
roll all my own widgets using cells and the little bit of stuff from the OS
listed above. And I created a pretty simple app framework to manage the
display and event-handling of those widgets.
Once I get that bundled up portably between win32 Lisp implementations I'll
share it, and I think folks will see that they can use it pretty easily
without necessarily buying into my assumptions. They'll have the source for
all the widgets, so they can just roll their own easily. And if they do not
like the way the larger framework works they can just hack it up as they see
fit.
That said, I am able to do pretty much whatever I want very easily with the
existing framework, so I expect folks will more often roll their own widgets
than alter the framework. And where the framework is a problem, I would
probably fix it myself (or adopt contributed fixes).
kenny
clinisys
Fred Gilham
> Are there reasons why overhauling / modernizing (if that is
> applicable) Garnet would not be a great idea? Even considering its
> (possible) shortcommings, wouldn't it still be easier to remedy
> those than to restart from scratch?
Garnet is a good GUI toolkit, but it isn't based on CLOS. I used to
think this didn't matter until I learned CLOS.
As I said to one correspondent, Garnet has a lot of neat features,
including browsers and inspectors for Garnet objects. Unfortunately,
when you've got a browser for Garnet objects, that doesn't give you a
browser for CLOS objects.
This is why I myself am focusing on CLIM and McCLIM. The design is
such that it's pretty easy to get cross-platform portability --- all
someone has to do is write a backend for the platform. Or if your
platform has X, you're home free. Tim Moore demoed it at the Lisp
conference running under OpenMCL on a Mac Powerbook.
There are a couple things I like about Garnet that aren't in CLIM,
such as constraints and its interactor model for dealing with user
input, where event handling is presented to the programmer as a set of
Garnet objects. But CLIM also has many interesting features, such as
presentations, output recording, formatted output, its use of extended
streams for window I/O, the whole command processor structure and so
on.
This is what I like about Lisp. One constantly runs into
mind-stretching things wherever one looks. Kenny complains a bit
about the `learning curve' issue. But I, for one, like climbing
learning curves, kinda the hacker version of rock climbing I
suppose. :-)
--
Fred Gilham gil...@csl.sri.com
When trying to reach the lowest common denominator, you have to be
prepared for the occasional division by zero.
Kenny Tilton
nutshell:
Cells are a kind of constraint, so simple tho that constraint is the
wrong word. Cells let you treat CLOS slots like spreadsheet cells, with
arbitrary Lisp code as the formula. Like a spreadsheet cell, the slot
gets recalculated automatically on changes to any other cell accessed
dynamically during the slots most recent calculation. Dataflow, in other
words. Data enters the model when event-handling code sets "system"
cells to some literal value. The model manifests change via so-called
echo functions invoked when a cell changes value.
They were developed originally to facilitate complex GUI layout, now I
use them for everything. I even managed to mix them into AllegroStore,
Franz's persistent ODB, so our home-brew browser transparently stays
current with the changing DB, and the DB can validate new data as it
arrives or even (if I ever come up with a need) update itself in light
of other updates--maybe creating also an email notification when it sees
a new shipment record being created. Something like that.
Fred Gilham
Not following up directly to my post, but for those who are
interested, there's a CLOS/CLUE based GUI toolkit called XIT. It
contains an inspector (a `meta-system') and a GUI-building toolkit.
I put a modified copy of it that works under CMU Lisp at
ftp:/ftp.csl.sri.com/pub/users/gilham/xit-mod-fmg.tar.gz.
To build it, extract it into some directory somewhere (you should have
100 mb or so available when you're doing this), go into the xit/clue
directory, edit the Makefile.cmu changing all the "/homes/gilham"
paths into something appropriate for your site, then type make. You
should get a clue.core file.
Then go up to the main xit directory, fix the Makefile.cmu there in
the same way. Also fix the paths in defsystem.lisp. Then type make.
You should wind up with an xit.core file.
Then go into the xit/examples directory, do (assuming you invoke CMU
Lisp as `lisp')
lisp -core ../xit.core
and
(load "start-demo")
Hit return and you should be up and running.
The license is unfortunately rather strict --- I'm considering my
distribution `personal use' but probably somebody could get mad at me
if they wanted to. But when I corresponded a couple years ago with
the last remaining `DRUID' guy, he seemed to not be too interested in
XIT any more. The problem is that it's hard to get people interested
in it without giving them a working version. Anyway I provided the
original distribution with my changes so anyone who cares can figure
out what I did.
A couple comments --- it runs pretty fast on a reasonable machine
(i.e. 500-1000 mHz or so). It can be a little slow when it loads
systems on the fly. It has a few bugs (such as the file browser).
The code was originally cltl1 and I had to puzzle out some stuff to
update it, and I'm not sure I did everything right. There are still
some `eval's in the code that I don't think belong there but I
couldn't, at the time, figure out how to get rid of them.
There is a color-selector that one can use to change the default
background and other colors from the medium-gray they start out with.
The keyboard stuff needs to be re-done to use key events rather than
actual character names like it does now.
I don't think this is really as viable as Garnet because there's no
cross-platform infrastructure. But it's interesting as a fairly well
developed CLOS-based X toolkit for Lisp.
--
Fred Gilham gil...@csl.sri.com || "If I thought there was anything at
all in your arguments, I should have to be not only a theist, but an
Episcopalian to boot," he said, after one interchange, reckoning that
since Episcopalianism was, in his book, that than which nothing could
be worse, this was an effective reductio ad absurdum. - J. R. Lucas
Thomas F. Burdick
> > Are there reasons why overhauling / modernizing (if that is
> > applicable) Garnet would not be a great idea? Even considering its
> > (possible) shortcommings, wouldn't it still be easier to remedy
> > those than to restart from scratch?
>
> Garnet is a good GUI toolkit, but it isn't based on CLOS. I used to
> think this didn't matter until I learned CLOS.
In my experience, it matters, but it's not the end of the world. I
have a fairly straightforward KR--CLOS bridge (KR is the
object+constraints system used by Garnet) that works well enough, in
practice. It does create the complication that you need to decide
where something will primarily live, in CLOS or in KR, but you can
have reflections in the other fairly easily.
A Garnet-alike that was more CLOS-friendly would be nice, though. I'm
not sure it'd get me to stop using Garnet (there's such a nice
development setup in there!) ... but it'd be worth considering.
Fred Gilham
> Not following up directly to my post, but for those who are
> interested, there's a CLOS/CLUE based GUI toolkit called XIT. It
> contains an inspector (a `meta-system') and a GUI-building toolkit.
Oops, I have to follow up my own post after all. :-)
The instructions I gave for XIT only talked about fixing the Makefile
and defsystem.lisp files in the top level directory and the clue
directory.
Actually you have to fix all of them --- just look in all the
subdirectories for Makefiles and defsystem.lisp files and edit them
appropriately. (It's just fixing pathnames.)
Sorry about that.
--
Fred Gilham gil...@csl.sri.com
Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of
our most gifted fellow humans in thinking previously impossible
thoughts. E. Dijkstra
CY
> Fred Gilham <gil...@snapdragon.csl.sri.com> writes:
>
> > > Are there reasons why overhauling / modernizing (if that is
> > > applicable) Garnet would not be a great idea? Even considering its
> > > (possible) shortcommings, wouldn't it still be easier to remedy
> > > those than to restart from scratch?
> >
> > Garnet is a good GUI toolkit, but it isn't based on CLOS. I used to
> > think this didn't matter until I learned CLOS.
>
> In my experience, it matters, but it's not the end of the world. I
> have a fairly straightforward KR--CLOS bridge (KR is the
> object+constraints system used by Garnet) that works well enough, in
> practice. It does create the complication that you need to decide
> where something will primarily live, in CLOS or in KR, but you can
> have reflections in the other fairly easily.
>
> A Garnet-alike that was more CLOS-friendly would be nice, though. I'm
> not sure it'd get me to stop using Garnet (there's such a nice
> development setup in there!) ... but it'd be worth considering.
Is the bridge available somewhere? That sounds like an interesting setup.
CY
Thomas F. Burdick
No. It's in a mess of my personal Garnet code that's not exactly
... how shall I say this .. in a state I'd like to share with the
general public right now. At some point, I'd like to clean up my
Garnet tools and share them (or some of them). However, writing a
simple KR--CLOS bridge is easy enough that if it sounds interesting,
you should just try to do it yourself.
Paul Tarvydas
>
>
> Rajappa Iyer wrote:
>
> fascinating effort! Tk must really be something. thx for the lead.
>
The best thing about Tk, IMO, is its simplicity. They managed to create a
powerful gui and drawing system without forcing OOP down your throat - an
amazing feat.
pt
Paul Tarvydas
> Tk is (by current standards) nothing particularly special. For the
...
> The successor to STk seems to be using Gtk, so that's another vote for
I disagree, but then I might be looking at this from a different
perspective.
I think that Tk is unique in that it invented a paradigm for solving the GUI
and drawing problems in a way that has not yet been duplicated. In Tcl/Tk
everything seems to be easy, short and sweet. Tcl/Tk deserves study.
Hello world in Tcl/Tk (2 lines):
button .but -text "Hello World"
pack .but
Hello world in Gtk (from
http://www.gtk.org/tutorial/ch-gettingstarted.html#SEC-HELLOWORLD with
comments removed, about 24 lines):
#include <gtk/gtk.h>
void hello( GtkWidget *widget,
gpointer data )
{
g_print ("Hello World\n");
}
gint delete_event( GtkWidget *widget,
GdkEvent *event,
gpointer data )
{
g_print ("delete event occurred\n");
return TRUE;
}
/* Another callback */
void destroy( GtkWidget *widget,
gpointer data )
{
gtk_main_quit ();
}
int main( int argc,
char *argv[] )
{
GtkWidget *window;
GtkWidget *button;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (G_OBJECT (window), "delete_event",
G_CALLBACK (delete_event), NULL);
g_signal_connect (G_OBJECT (window), "destroy",
G_CALLBACK (destroy), NULL);
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
button = gtk_button_new_with_label ("Hello World");
g_signal_connect (G_OBJECT (button), "clicked",
G_CALLBACK (hello), NULL);
g_signal_connect_swapped (G_OBJECT (button), "clicked",
G_CALLBACK (gtk_widget_destroy),
G_OBJECT (window));
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (button);
gtk_widget_show (window);
gtk_main ();
return 0;
}
...
> The core system never became particularly portable to languages other
> than Tcl, though, despite the efforts of Perl people to contribute
> patches to make it so. So if you want to go the Tk route, take the
> version from Perl or Python, not the original.
>
I've wanted to bolt Tcl/Tk into LW and have started a few times. I looked
at Python and Perl/Tk in the hope of stealing their code. From what I
remember, my observations were:
- Python appears to embed itself into Tcl/Tk (the main loop belongs to Tk,
it calls the Python interpreter) and Python passes strings to the Tcl
interpreter (via TkInter).
- Perl/Tk ripped all of the Tcl-related code out of Tk and converted it into
a C library. When Tcl/Tk was upgraded from version 7 to 8, it appears that
the Perl/Tk people had to re-do the job and stopped tracking Tcl/Tk a few
versions ago.
- GCL gives the appearance of directly mapping Tk commands onto CL. Looking
under the hood, I found that it was a cute use of lisp macros that
communicated with a Tcl/Tk interpreter, living in another process, via
sockets.
- I looked at the C code for Tk itself, esp. the Windows stuff. It was
readable. Gave me the impression that it could be reverse-engineered.
I'm beginning to wonder whether the "right thing" to do is to
reverse-engineer the design of Tk (the Tk paradigm (hierarchical names,
tags, commands, etc.), plus how the cross-platform portability stuff was
handled) and rewrite it in CL. Eh?
pt
Kenny Tilton
just thinking out loud here and not addressing anything Paul raised:
Well, for my project anyway, my feeling is "lisp or bust!". opengl would
be the only non-OS technology to leverage. This is not to say that at
some point I or others won't decide to leverage Java SWT or gtk or
whatever, but for now I just want to get the universal cl gui going.
the native thing seems to be a well-understood problem. swt is handling
it the obvious way, support the union of all targets' widgets, going
native where the target has the widget. a CL gui could do the same by
mirroring the SWT effort, saving us a lot of study.
i do not see a justification for adopting some non-CL gui just to avoid
what would be a tedious but otherwise highly tractable effort.
Kenny Tilton
Paul Tarvydas wrote:
>
> I'm beginning to wonder whether the "right thing" to do is to
> reverse-engineer the design of Tk (the Tk paradigm (hierarchical names,
> tags, commands, etc.), plus how the cross-platform portability stuff was
> handled) and rewrite it in CL. Eh?
I think once y'all see what it is like to build a GUI with Cells you'll
lose interest in CLIM, Tk, GTk, etc. But to get the native thing...
...what if the CL vendors joined Eclipse and put some resources into
doing a CL version of SWT? Or do CL vendors like competing on the basis
of their GUI frameworks? I would guess not.
Tim Bradshaw
> i do not see a justification for adopting some non-CL gui just to
> avoid what would be a tedious but otherwise highly tractable effort.
Avoiding tedium or, in other words, saving time, especially time spent
by highly-skilled and highly-paid people is sort-of what programming
is about.
Of course, now everyone has realised that IT is bogus, skilled person
time is probably a lot cheaper than it was two years ago...
--tim
Tim Bradshaw
> ...what if the CL vendors joined Eclipse and put some resources into
> doing a CL version of SWT? Or do CL vendors like competing on the
> basis of their GUI frameworks? I would guess not.
Me too, but they probably have bitter experience of just how expensive
collaborative efforts can be (like CL or CLIM or (I guess) the CL
CORBA bindings). Collaborative single-implementation (rather than
standard-based) efforts are cheaper, I guess.
--tim
Bruce Stephens
> Bruce Stephens wrote:
>
>> Tk is (by current standards) nothing particularly special. For the
> ...
>> The successor to STk seems to be using Gtk, so that's another vote for
>
> I disagree, but then I might be looking at this from a different
> perspective.
>
> I think that Tk is unique in that it invented a paradigm for solving the GUI
> and drawing problems in a way that has not yet been duplicated. In Tcl/Tk
> everything seems to be easy, short and sweet. Tcl/Tk deserves study.
>
> Hello world in Tcl/Tk (2 lines):
>
> button .but -text "Hello World"
> pack .but
>
> Hello world in Gtk (from
> http://www.gtk.org/tutorial/ch-gettingstarted.html#SEC-HELLOWORLD with
> comments removed, about 24 lines):
[yucky C deleted]
Sure, but that's a bit unfair. A better example would be something in
Perl/gtk or Python/gtk or something.
But I agree: when I want to write some kind of GUI, the first thing I
go for is Tcl/Tk. It's a mature system that works well and that I'm
comfortable using, for all the limitations of Tcl as a language (it
could really use closures, for example).
(Gtk/GNOME took some ideas from Tk, and improved them. For example,
Tk's canvas scales relatively poorly as the number of items increases.
GNOME's canvas (heavily inspired by Tk's) is just better designed, and
scales well enough for it to be used for constructing spreadsheets and
the like.)
> ...
>> The core system never became particularly portable to languages other
>> than Tcl, though, despite the efforts of Perl people to contribute
>> patches to make it so. So if you want to go the Tk route, take the
>> version from Perl or Python, not the original.
>
> I've wanted to bolt Tcl/Tk into LW and have started a few times. I looked
> at Python and Perl/Tk in the hope of stealing their code. From what I
> remember, my observations were:
>
> - Python appears to embed itself into Tcl/Tk (the main loop belongs to Tk,
> it calls the Python interpreter) and Python passes strings to the Tcl
> interpreter (via TkInter).
>
> - Perl/Tk ripped all of the Tcl-related code out of Tk and converted it into
> a C library. When Tcl/Tk was upgraded from version 7 to 8, it appears that
> the Perl/Tk people had to re-do the job and stopped tracking Tcl/Tk a few
> versions ago.
Yes, in spite of them trying to work with the Tcl/Tk people to get the
code back into the core of Tk. There were bad feelings about that.
> - GCL gives the appearance of directly mapping Tk commands onto CL. Looking
> under the hood, I found that it was a cute use of lisp macros that
> communicated with a Tcl/Tk interpreter, living in another process, via
> sockets.
Yes, which doesn't strike me as a bad approach.
> - I looked at the C code for Tk itself, esp. the Windows stuff. It was
> readable. Gave me the impression that it could be reverse-engineered.
Yes, whenever I've looked at the Tcl or Tk code, I've found it to be
unusually readable.
> I'm beginning to wonder whether the "right thing" to do is to
> reverse-engineer the design of Tk (the Tk paradigm (hierarchical
> names, tags, commands, etc.), plus how the cross-platform
> portability stuff was handled) and rewrite it in CL. Eh?
Maybe, but you still need the underlying code to actually draw stuff,
which presumably has to be C, and doesn't that work out to be close to
what Tk is?
Kenny Tilton
> * Kenny Tilton wrote:
>
>>i do not see a justification for adopting some non-CL gui just to
>>avoid what would be a tedious but otherwise highly tractable effort.
>
> Avoiding tedium or, in other words, saving time, especially time spent
> by highly-skilled and highly-paid people is sort-of what programming
> is about.
I do not mean that application developers have to slog through the task
again and again, I mean a relatively small open source effort could mow
through the task in short order. And you don't have to do the whole
thing in one go, start with the basics and expand as needed.
As someone worried recently, once an API of a neat new toolkit to be
sold has been worked out (the hard part), replicating the guts behind it
can be done in short order (ripping off the person who worked out the
API). In this case, SWT is open source and the license is cool, so we
are not even ripping anyone off. We leverage the Java SWT effort to get
a Lisp SWT easily, and at the same time grease the skids for anyone (a)
doing Java and (b) looking for a better way. Maybe we end up giving back
to JSWT.
You said you wanted native look/feel (and it does seem to be widely
accepted as a Good Thing) and I guess you would also dig getting it from
a Universal CL GUI (UCLGUI? Pronounced "ugly"? Or Common Lisp Open GUI
(CLOG)? Anyway...). Translating SWT to CL is probably the way to go,
with my second choice being using the JSWT from Lisp. I know ACL offers
interfaces between Lisp and Java, but is there a universal way to do
that? Anyway...
I have been wondering about the burgeoning ILUG-NY... what exactly does
a user group do? I would think an open source project is the only way to
really motivate such a thing.
Granted, big assumptions behind my thinking:
-- CL needs a UCLGUI, especially to grow, and especially to make
feasible a CL plug-in for browsers (another thing I am assuming would be
good for CLers and good for CL)
-- a self-respecting HLL shouldn't rely on another HLL for something as
fundamental as a GUI. Especially if the indirection will hurt performance.
Maybe these assumptions are mistaken.
Kenny Tilton
Understood re single-imp being a snap, but eclipse/swt seems to be going
pretty well (from out here in the bleachers), so it's not as if they
would be getting into an unknown. It's more like a free ride. I mean,
they have resources going into their GUIs now, yes? And CLIM.
Hell, they can pull people off GUIs and CLIM and put them on LSWT
and be done with the issue once and for all. Probably lower their GUI
R&D costs on day one.
Marc Spitzer
>
> I have been wondering about the burgeoning ILUG-NY... what exactly
> does a user group do? I would think an open source project is the only
> way to really motivate such a thing.
>
Well at one extreme we could get together and change the world with
CL or, at the other, we could drink some beers. I have a feeling that
it will be somewhere in the middle.
marc
----
first post using GNUS, hope it works
Tim Bradshaw
> I do not mean that application developers have to slog through the
> task again and again, I mean a relatively small open source effort
> could mow through the task in short order. And you don't have to do
> the whole thing in one go, start with the basics and expand as
> needed.
I didn't mean application people, I meant people working on the OSS
effort. Those are likely to be people donating time who have busy
lives and real jobs (though, as I said, maybe not any more...), who
have a wide choice of other things they could do. I think you need to
make it non-tedious for them.
However, I may be mistaken about this - lots of OSS projects seem to
involve `let's reimplement this non-free thing with some bells &
whistles' which I'd find a bit tedious in general, so maybe I'm just
wrong.
> You said you wanted native look/feel (and it does seem to be widely
> accepted as a Good Thing) and I guess you would also dig getting it
> from a Universal CL GUI (UCLGUI? Pronounced "ugly"? Or Common Lisp
> Open GUI (CLOG)? Anyway...).
Yes, I'd like both these things (wouldn't anyone (:-)).
--tim
Tim Bradshaw
> Hell, they can pull people off GUIs and CLIM and put them on LSWT
> and be done with the issue once and for all. Probably lower their GUI
> R&D costs on day one.
Well, they can't easily, because they have users of the existing GUIS
and CLIM who are paying good money for support and will (a) scream and
(b) go elsewhere and kill the company...
--tim
Kenny Tilton
Tim Bradshaw wrote:
> * Kenny Tilton wrote:
>
>>I do not mean that application developers have to slog through the
>>task again and again, I mean a relatively small open source effort
>>could mow through the task in short order. And you don't have to do
>>the whole thing in one go, start with the basics and expand as
>>needed.
>
>
> I didn't mean application people, I meant people working on the OSS
> effort. Those are likely to be people donating time who have busy
> lives and real jobs (though, as I said, maybe not any more...), who
> have a wide choice of other things they could do. I think you need to
> make it non-tedious for them.
OK, I think you have checkmate in two: (a) I should not bother doing a
UCLG if it does not use native widgets, (b) doing both "universal" and
"native" is a huge project i could never handle alone, and (c) if I take
out the hard part of the huge project no one will help with the easy part.
What if some killer (aka "hard") Java-parsing macro can automate the
tedious bit? Anyway, I resign. UCLG won't do native widgets.
Kenny Tilton
"Think you can or think you can't, either way you'll be right."
Actually I have no idea what vendor resources go into GUI/CLIM
dev/maintenance or whether they prefer competing on the basis of those,
so this bit has all been wild speculation anyway.
Paul Tarvydas
> [yucky C deleted]
>
> Sure, but that's a bit unfair. A better example would be something in
> Perl/gtk or Python/gtk or something.
>
I hadn't thought of that. OTOH, when I looked, I found:
#!/usr/bin/perl -w
use Gtk; # load the Gtk-Perl module
use strict; # a good idea for all non-trivial Perl scripts
set_locale Gtk; # internationalize
init Gtk; # initialize Gtk-Perl
# convenience variables for true and false
my $false = 0;
my $true = 1;
# widget creation
my $window = new Gtk::Window( "toplevel" );
my $button = new Gtk::Button( "Goodbye World" );
# callback registration
$window->signal_connect( "delete_event", \&CloseAppWindow );
$button->signal_connect( "clicked", \&CloseAppWindow );
# show button
$button->show();
# set window attributes and show it
$window->border_width( 15 );
$window->add( $button );
$window->show();
# Gtk event loop
main Gtk;
# Should never get here
exit( 0 );
### Callback function to close the window
sub CloseAppWindow
{
Gtk->exit( 0 );
return $false;
}
# END EXAMPLE PROGRAM
I would argue that this exposes way too much detail to the "application
programmer" (someone who wants to use graphics, not implement a graphics
package itself). Maybe this is where I'm missing the point - you are
(probably) saying that Gtk is a well-implemented library that a graphics
"language" can be built upon, and I'm arguing that Gtk is insufficiently
simple to be the graphics language that should be exposed to "application
programmers", whereas Kenny is saying that he's going to show us a
sufficiently simple language (based on Cells).
[Just out of interest, another simple "graphics language" that I've always
admired was Kernighan's PIC http://www.cs.bell-labs.com/10thEdMan/pic.pdf]
> Tk's canvas scales relatively poorly as the number of items increases.
> GNOME's canvas (heavily inspired by Tk's) is just better designed, and
Out of interest, do you know how/why it's better?
>> that communicated with a Tcl/Tk interpreter, living in another process,
>> via sockets.
>
> Yes, which doesn't strike me as a bad approach.
Other than for experimentation, this leaves me feeling queasy. I've tried
to deliver a "product" done this way under Windows and ran into various
Windows-caused headaches (Win98 actually ran out of sockets after the 8th
one). I would tend towards a more-integrated result.
> Maybe, but you still need the underlying code to actually draw stuff,
> which presumably has to be C, and doesn't that work out to be close to
> what Tk is?
I experimented with and had reasonable success calling Win32 primitives
directly from LWW using the FLI. I even managed to create a stand-alone
window whose Windows WM_xxx callbacks were handled in Lisp (lisp FLI
function pointers passed to Windows as the callback address), running at
the same time as the LWW IDE with neither tripping over the other (a trick
I learned by reading the Tk source code :-). So, theoretically, no C is
required whatsoever.
pt
Tim Bradshaw
> OK, I think you have checkmate in two: (a) I should not bother doing a
> UCLG if it does not use native widgets, (b) doing both "universal" and
> "native" is a huge project i could never handle alone, and (c) if I
> take out the hard part of the huge project no one will help with the
> easy part.
No, I think it's just important to avoid the tedium. Apart from
anything else, anything that is tedious (so: lots of grunt work) will
need to be redone when the underlying native widgets change, so you
need to automate it...
> What if some killer (aka "hard") Java-parsing macro can automate the
> tedious bit?
Yes, this is a win!
--t
Kenny Tilton
> * Kenny Tilton wrote:
>>tedious bit?
>
>
> Yes, this is a win!
>
Glad you like it, because i am assigning this task to you in return for
your raining all over the UCLG parade.
:)
Bruce Stephens
> Bruce Stephens wrote:
[...]
>> Tk's canvas scales relatively poorly as the number of items increases.
>> GNOME's canvas (heavily inspired by Tk's) is just better designed, and
>
> Out of interest, do you know how/why it's better?
In a nutshell, Tk's canvas stores its items in a list, so some
operations will be linear in the number of items. (Now, things mostly
work OK, since there's some cunning remembering of the current item,
and that's the one that gets checked first. But when that fails,
searching goes back to the linear search.)
GNOME's uses (allows, rather) the use of a tree, so in those common
cases where you've got geometrically related groups of items, you can
stick them in as subtrees.
[...]
Paolo Amoroso
Burdick) wrote:
> Garnet tools and share them (or some of them). However, writing a
> simple KR--CLOS bridge is easy enough that if it sounds interesting,
> you should just try to do it yourself.
In a message posted to the Garnet mailing list, a user discussed something
similar. I don't have it handy, sorry. But the list archive should still be
available.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
cr88192
> Kenny Tilton <kti...@nyc.rr.com> wrote in message
> news:<3DC6D1D1...@nyc.rr.com>...
>> Thomas F. Burdick wrote:
>> > Kenny Tilton <kti...@nyc.rr.com> writes:
>> >
>> >
>> >>I am planning to get to work at last on a common CL gui framework.
>> >>Someone asked me in email what I had in mind, I thought I would answer
>> >>here to get folks' input. In no particular order:
>> >>
>> >>- lightweight (as contrasted with CLIM)
>> >
>> >
>> > How about as contrasted with Garnet ;-)
>>
>> Not sure. IIRC, garnet was pretty straightforward on the GUI bit, yes?
>
> I guess I'm pretty late to this discussion, and this isn't strictly
> relevant to the question at hand, but in case anyone didn't know
> Garnet still exists, is public domain, and is available for download
> at http://garnetlisp.sf.net. In my admittedly limited experience with
> Garnet, it has seemed to perform fairly well on clisp once it is
> compiled. Garnet has been quiet for a long time now, but there is
> hope of life being breathed back into it in the future.
>
> Just thought I'd let you know the resource is available, if it can be
> of use to you.
sort of unrelated. I had looked at garnet (somewhat briefly reading some of
the papers, so I may be missing details...), and had noticed that in many
ways the object system they used is similar to the object system currently
being used in my lang. mostly what I found interesting was their
descriptions of style, for which my design differs.
my objects differ from other prototype systems in that slots are not really
fundamental to the objects (though they are implemented as part of the
object for efficiency and earlier design reasons).
my objects mostly just perform pattern/matching and dispatch. my pattern
matcher in many cases will match keywords to symbols (with an equivalent
base), allowing constraints (except that they would be recomputed on every
use).
define pyth-obj
newobject root-obj
a 3
b 4
(c:) (sqrt ((a * a) + (b * b)))
^ pyth-obj.c => 5
there also exists null-obj, however this would not work for it as null-obj
does not know about either slots or binding (and thus has to be manipulated
using generic functions). null-obj was intended to allow implementing
things like pattern matched functions and pipes, but I have not gotten
around to it yet.
objects can be composed easily enough by cloning/modification, but I had
started designing my gui to make use of functions as the preferred style
(as in many cases I can get a function to be more concise, though objects
are more powerful).
for many simple objects the function ends up cloning the prototype and
making a few adjustments.
some more complicated objects (such as stacks/boxes), are better
implemented as functions, as they step over their arguments to figure where
to put them, and at the same time, their own properties (at the same time
creating slots to hold the child objects, by extracing a name and
similar...).
I didn't particularly follow the idea behind interactors though.
my system works by just passing basic messages to objects, and if the
object does something with the message, then whatever happens.
the gui so far is just a few bits which were hacked together, but I have
considered starting to actually design it. recently I have been reading
stuff to get ideas as to how it will be put together.
keep in mind, my lang is still mostly intended to be a toy of mine, so not
much is really being designed for "practical use", except what I deem
useful for use in my own projects (for me it serves this use so far, as a
kind of command/scripting/glue/... language).
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Tim Daly, Jr.
Paul Tarvydas <tarv...@attcanada.ca> writes:
...
> Hello world in Tcl/Tk (2 lines):
>
> button .but -text "Hello World"
> pack .but
>
Hello world using clgtk:
(defun hello ()
(gtk:with-connection ()
(let ((window (gtk:gtk-window-new :toplevel))
(button (gtk:gtk-button-new-with-label "Hello, world!")))
(gtk:signal-connect window :destroy
(lambda (foo)
(return-from hello)))
(gtk:signal-connect button :clicked
(lambda (foo)
(gtk:widget-destroy window)))
(gtk:container-add window button)
(gtk:widget-show button)
(gtk:widget-show window))
(gtk:event-loop)))
It's not as simple as your tcl/tk example, but you could easily write
macros or wrapper functions to make it so.
-Tim
Fred Gilham
Here's garnet.
(garnet-load "gadgets:text-buttons-loader")
(create-instance 'mywindow inter:interactor-window
(:aggregate (create-instance 'myagg opal:aggregate)))
(create-instance 'mytext gg:text-button
(:string "Hello World")
(:selection-function
#'(lambda (gadget value)
(declare (ignore gadget value))
(opal:destroy mywindow))))
(opal:add-component myagg mytext)
(opal:update mywindow)
--
Fred Gilham gil...@csl.sri.com
"In the 20th century, more citizens were killed by their own
governments than by foreign enemies....totalitarianism first of all
regards its own people as the enemy." --- Arnold Beichman
Kenny Tilton
(defun hello-world ()
(mg-reset 'MGSystem)
(make-FWFrameWindow :helloworld 'FWFrameWindow 100 100 100 100
:kids (list (mkPart :good-bye (CTButton)
:pOffsetH 10 :pOffsetV 10
:text$ "Hello, world."
:controlaction
(lambda (button event)
(declare (ignorable button event))
(close (upper button FWFrameWindow)))))))
Kenny Tilton
(defun hello-world ()
(mg-reset 'MGSystem)
(setf (cs-logical-dpi) 96)
(make-FWFrameWindow :helloworld 100 100 200 100
:kids (list (mkPart :good-bye (CTButton)
:pOffsetH 10 :pOffsetV 10
:text$ (sm? (conc$
(if (eql self (^mouseImage (swdw)))
"Good-bye"
"Hello")
", world."))
:controlaction (lambda (self event)
(declare (ignorable button event))
(close (swdw)))))))
Button shows "hello..." until the mouse moves over it, then
"good-bye...". The swdw macro expands to (window self).
Mario S. Mommer
Fred Gilham <gil...@snapdragon.csl.sri.com> writes:
> > Are there reasons why overhauling / modernizing (if that is
> > applicable) Garnet would not be a great idea? Even considering its
> > (possible) shortcommings, wouldn't it still be easier to remedy
> > those than to restart from scratch?
>
> Garnet is a good GUI toolkit, but it isn't based on CLOS. I used to
> think this didn't matter until I learned CLOS.
Ok - granted. That's of course nothing you can, like, ''fix'' :-)
> This is what I like about Lisp. One constantly runs into
> mind-stretching things wherever one looks. Kenny complains a bit
> about the `learning curve' issue. But I, for one, like climbing
> learning curves, kinda the hacker version of rock climbing I
> suppose. :-)
And in Lisp, the view from the top is also quite amazing.
Mario S. Mommer
Janis Dzerins
> Button shows "hello..." until the mouse moves over it, then
> "good-bye...". The swdw macro expands to (window self).
How about using a symbol macro? (^mouseImage swdw) would look better
than (^mouseImage (swdw)).
--
Janis Dzerins
If million people say a stupid thing, it's still a stupid thing.
Kenny Tilton
Janis Dzerins wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>Button shows "hello..." until the mouse moves over it, then
>>"good-bye...". The swdw macro expands to (window self).
>
>
> How about using a symbol macro? (^mouseImage swdw) would look better
> than (^mouseImage (swdw)).
Good idea. I only learned about symbol macros recently, here on c.l.l,
in fact, god bless it.
What's the rule of thumb? If the macro has no args, use a symbol macro?
Gabe Garza
> Good idea. I only learned about symbol macros recently, here on c.l.l,
> in fact, god bless it.
>
>
> What's the rule of thumb? If the macro has no args, use a symbol macro?
Personally, I'd say "If a macro has no args and expands into something
that's setf-able and it makes sense to think of the resulting symbol
as a 'variable' of some sort".
Gabe Garza
Hannah Schroeter
Gabe Garza <g_g...@ix.netcom.com> wrote:
>[...]
>Personally, I'd say "If a macro has no args and expands into something
>that's setf-able and it makes sense to think of the resulting symbol
>as a 'variable' of some sort".
Is there a reason why you can't define global symbol-macros, but only
local ones with symbol-macrolet? Or have I missed something?
Kind regards,
Hannah.
Nils Goesche
> Gabe Garza <g_g...@ix.netcom.com> wrote:
> >Personally, I'd say "If a macro has no args and expands into
> >something that's setf-able and it makes sense to think of the
> >resulting symbol as a 'variable' of some sort".
>
> Is there a reason why you can't define global symbol-macros, but only
> local ones with symbol-macrolet? Or have I missed something?
DEFINE-SYMBOL-MACRO?
Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Hannah Schroeter
Nils Goesche <car...@cartan.de> wrote:
>[...]
>> Is there a reason why you can't define global symbol-macros, but only
>> local ones with symbol-macrolet? Or have I missed something?
>DEFINE-SYMBOL-MACRO?
Thanks, I've just missed things. But it's fine in the HyperSpec.
Kind regards,
Hannah - who should be making an appointment with an ophtalmologist.
thelifter
> I am planning to get to work at last on a common CL gui framework.
> Someone asked me in email what I had in mind, I thought I would answer
> here to get folks' input. In no particular order:
So what have you decided to do now? IIRC you wanted to go the SWT way?
Please keep us informed, you might find people to help you...
best regards...
Kenny Tilton
thelifter wrote:
> Kenny Tilton <kti...@nyc.rr.com> wrote in message news:<3DC55242...@nyc.rr.com>...
>
>>I am planning to get to work at last on a common CL gui framework.
>>Someone asked me in email what I had in mind, I thought I would answer
>>here to get folks' input. In no particular order:
>
>
> So what have you decided to do now? IIRC you wanted to go the SWT way?
OK, this is embarrassing, but I may as well ask. We have this FFI thang,
right. Which /says/ "foreign function", not as far as I can make out
means "foreign 'c' function interface". Confirming this i see ACL
bragging about Java-ACL interop.
> Please keep us informed, you might find people to help you...
as per a separate thread, i'm off to pythonland to round up a posse (and
add Python to the resume <g>). when I get back (posse or no)...
...still tossing and turning. one radical new thought is simply to bolt
Cells /on top of/ whatever folks are already using. ie, drive ACL CG and
LW CAPI and some popular X GUI and etc etc with Cells. That would be
very practical and boring, but maybe it is also the Right Thing.
otoh, I am tempted now to run up the white flag on "practical" and just
go party with OpenGL and the GLUT (if indeed we can manage the main loop
issue). The advantage there is that I can leverage the universality of
OGL and GLUT /and/ my GUI/app framework.
A minor setback would be GLUT not working out, tho the GLUT writeup
makes it sound like just wrestling the diff window systems to the ground
would be a hairy project. anyway...
at this point this latter easy-way-out, just for the fun of giving CL a
GUI (native be damned!), sounds like the only thing I could hope to pull
off solo. then if folks fall in love with cells I can share my Cells-CG
code in which I drove ACL Common Graphics with Cells and folks could
clone that to other frameworks.