Re: troll's food (python vs lisp)
From: Kenny Tilton (ktilton_at_nyc.rr.com)
Date: 09/18/04
- Next message: Antonio Menezes Leitao: "Re: pprint troubles"
- Previous message: Patrick May: "Re: troll's food (python vs lisp)"
- In reply to: Peter Herth: "Re: troll's food (python vs lisp)"
- Next in thread: Peter Herth: "Re: troll's food (python vs lisp)"
- Reply: Peter Herth: "Re: troll's food (python vs lisp)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 18 Sep 2004 10:57:06 GMT
Peter Herth wrote:
> Fred Gilham wrote:
>
>>Peter Herth wrote:
>>
>>>For lisp GUI try Ltk :)
>>
>>It's a point of pride with me that Lisp can host its own damn GUIs.
>>None of this ``talk to something at the end of a socket that's man
>>enough to do the drawing for you'' crud for me.
>
>
> It would be nice, if you could point out how this relates to Ltk.
LTk or any interface to Tk is nifty, but it is not native. It is Tk. One
is restricted to Tk widgets and items (in a Tk canvas widget). The whole
thing works the way Tk says it will work. One gets anti-aliased text if
and only if TK on ones platform supports anti-aliased text. One does
layout The Tk Way. That hapens to be powerful, but one /is/ constrained
by the Tk design decisions.
A native GUI library gives the Lispnik an event stream and low-level
drawing. Widgets arise from Lisp code processing events and drawing. One
has the Lisp source to look at to understand or even debug a canned
widget. One can clone a widget and modify the Lisp to get a more or less
different widget by altering the low-level event handling and/or drawing.
Something like AllegroCl's Common Graphics gui lib or MCL's gui
framework are thin layers around the win32 or (back in the day) OS9
window system, such that one can easily custom-handle OS events or draw
custom widgets while at the same time using canned widgets where canned
behavior suffices.
Tk does offer some access to the event stream, so we are in a bit of a
gray area, but on the whole LTk is not a Lisp GUI, it is a Lisp
interface to a (fine) "C" GUI.
> So what in my opinion makes up a "native" GUI is foremost, that you can
> use it from your language in a seamless way, and that was the mayor goal
> of writing Ltk in contrast to bindings like "with-wish" which made the user
> to see and use Tk code.
I have been puzzled by this claim in the past. LTk hides some of the
work of talking to Tk, but one is still using Tk widgets and items and
needs to know their options. And one is still using the Tk layout
manager and needs to know how that works. Mind you, I do not see this as
a bad thing, because Tk itself is a fine toolkit with loads of options.
But the only way an LTk user can avoid stocking up on Tk manuals is to
limit oneself to the simple examples in the LTk demos. But real users
will quickly want to avail themselves of most of Tk's features--they
exist precisely because they are the things GUI programmers need.
In Celtic (my LTk derivative), all Tk widgets and items are exposed to
the Celtic developer with all options available, so as to give the user
the full power of Tk. The alternative would be to erect a new GUI
framework which only happens to be implemented by the Tk framework. Why
bother? Not simplicity; if the new framework has any success, users will
quickly demand all the functionality which led to Tk having as many
features as it does.
kt
-- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
- Next message: Antonio Menezes Leitao: "Re: pprint troubles"
- Previous message: Patrick May: "Re: troll's food (python vs lisp)"
- In reply to: Peter Herth: "Re: troll's food (python vs lisp)"
- Next in thread: Peter Herth: "Re: troll's food (python vs lisp)"
- Reply: Peter Herth: "Re: troll's food (python vs lisp)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|