<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thomas F. Burdick wrote:
<blockquote
cite="midb61efa90602070941j55dc8990g9f8bd08d81512fc6@mail.gmail.com"
type="cite">
<pre wrap="">On 2/6/06, Kenny Tilton <a class="moz-txt-link-rfc2396E" href="mailto:ktilton@nyc.rr.com"><ktilton@nyc.rr.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thomas F. Burdick wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The internal interface to callbacks is: create-name, add-callback,
remove-callback, and callback. Contrary to what the lambda-list of
what the last three would make you believe, callbacks are named by
strings, not symbols. You should get the name for a new callback from
create-name. I'll be fixing that in subversion if Peter doesn't beat
me to it.
</pre>
</blockquote>
<pre wrap="">Oh. Pity. Symbols are Good Things. I see no problem with symbols and
wish. Why complicate things with unnecessary rules (Thou shalt use strings.)
</pre>
</blockquote>
<pre wrap=""><!---->
I wasn't trying to enumerate a rule, just saying what the internal
interface inside Ltk is. The reason for that is that foo::bar is Tcl
syntax for its namespacing system, so if you want to send an arbitrary
identifier from Lisp to Tcl and back, a string is the easiest to do
right.
</pre>
</blockquote>
OK, makes sense. (Where did they get /that/ wacky namespace syntax?!)<br>
<blockquote
cite="midb61efa90602070941j55dc8990g9f8bd08d81512fc6@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Actually, I think LTk needs to evolve a little in regard to
communication with wish. I understand the desire to make things easy for
casual users, but I do not think that should extend to defining "an
internal interface", with strictures on communication with wish.
</pre>
</blockquote>
<pre wrap=""><!---->
Hmm, I really meant more "conventions used within Ltk" rather than
"internal interface". FWIW, the communication with wish could use an
overhaul to make it a little more robust. That said, there shouldn't
be anything you can't do with format-wish, read-data, senddata on the
Tk side, and the new hook Peter put into the event-handling mechanism.
</pre>
</blockquote>
What hook would that be? The one prompted by my whining, viz, to
dispatch any unrecognized first symbol to a generic handler users can
specialize?<br>
<blockquote
cite="midb61efa90602070941j55dc8990g9f8bd08d81512fc6@mail.gmail.com"
type="cite">
<pre wrap=""> At least, that's sufficient for everything Ltk does itself :-)</pre>
</blockquote>
<g> Well that certainly ducks my point: any successful library
will get pushed in ways the author cannot anticipate. Of course, one
can always hope for failure. :) That said, it may well be that the
pinhole interface (:callback or :data only) data is perfect, and that
power users can in fact achieve anything just by writing a suitable
proc, so I am going to shut up for a while.<br>
<br>
kt<br>
<br>
</body>
</html>