Prev: grabbing key presses
Next: Authentic Designer Handbags EVOGUER.COM 15% OFF DISCOUNT!!!!
From: Peter Herth on 17 Nov 2009 04:48
Tamas K Papp schrieb:

> I am not an expert on tk, but heard about things like tile. Is it
> possible to use ltk with that (sorry if the question is silly or
> nonsensical, I know very little about tk, just looking for something
> that "looks" better than the default appearance).
>

Hi Tamas,

the upcoming release of LTk uses Tile by default for its look and feel,
assuming you are using Tk 8.5 (which adds Tile as a "standard" package)

Peter
From: Tamas K Papp on 17 Nov 2009 05:30
On Tue, 17 Nov 2009 10:48:51 +0100, Peter Herth wrote:

> Tamas K Papp schrieb:
>
>> I am not an expert on tk, but heard about things like tile. Is it
>> possible to use ltk with that (sorry if the question is silly or
>> nonsensical, I know very little about tk, just looking for something
>> that "looks" better than the default appearance).
>>
>>
> Hi Tamas,
>
> the upcoming release of LTk uses Tile by default for its look and feel,
> assuming you are using Tk 8.5 (which adds Tile as a "standard" package)

Hi Peter,

Thanks, that would be really nice.

Would you consider making ltk available in a public repository, eg on
github (many lispers use it, it is quite nice). That way you could
have a "stable" branch, while interested people could use the
"development" branch before it is released.

Thanks,

Tamas
From: Peter Herth on 17 Nov 2009 05:58
Tamas K Papp schrieb:
> Would you consider making ltk available in a public repository, eg on
> github (many lispers use it, it is quite nice). That way you could
> have a "stable" branch, while interested people could use the
> "development" branch before it is released.

Just look here: http://ltk.rplay.net/svn/
The soon-to-be-merged current devlopment branch is:
http://ltk.rplay.net/svn/branches/ltk/repl/

There is also a LTk mailing list at:
http://common-lisp.net/cgi-bin/mailman/listinfo/ltk-user

Peter
From: Paul Griffioen on 17 Nov 2009 06:36
On Tue, 17 Nov 2009 10:01:25 +0100, Peter Herth wrote:

> Paul Griffioen schrieb:
>
>> I suspect that clTcl is also better synchronized with Tcl/Tk's events.
>> I don't know the latest version of Ltk, but if I remember correctly it
>> had some problems with error handling. Calls in clTcl block and catch
>> errors.
>
> I would be interested in what you mean by "better synchronized"? Those
> calls in LTk which are supposed to block on Tcl do so, and error
> handling is also working. I have to admit though, I really have to make
> a new release to ensure all LTk users use the cutting edge stuff :)
>
> Peter

I was referring to the following FIXME from Ltk's code:

"The problem here is that wish sends us error-messages on the same
stream that we use for our own communication. It would be good if we could
get the error-messages (that are presumably written to stderr) onto a
separate
stream. The current workaround is based on the observation that wish error
messages always seem to end on a newline, but this may not always be so.
READ-ALL would be a bad idea anyways, as in that case we could
accidentally
snarf a real message from the stream as well, if it immediately followed
an error message."

It has been a while since I looked at Ltk but I see now it is still in
the code. Issues with reading from Tcl/Tk streams led me to write a
reader for Tcl.

Was I correct in my statement that Ltk is limited to libraries that it
has wrappers for? What I like about Ltk is that it is completely in Lisp,
but I want complete access to Tcl/Tk. I don't mind programming in Tcl so
it's not a big deal for me, but a Lisp interface is nice.

Paul
From: Peter Herth on 17 Nov 2009 06:50
Paul Griffioen schrieb:


> I was referring to the following FIXME from Ltk's code:
>
> "The problem here is that wish sends us error-messages on the same
> stream that we use for our own communication. It would be good if we could
> get the error-messages (that are presumably written to stderr) onto a
> separate
> stream. The current workaround is based on the observation that wish error
> messages always seem to end on a newline, but this may not always be so.
> READ-ALL would be a bad idea anyways, as in that case we could
> accidentally
> snarf a real message from the stream as well, if it immediately followed
> an error message."

Hehe, the comment is still in the newest development version, but errors
should come back as an S-expression. All evaluation of Tcl code sent
from LTk now happens in a catch, which in the case of an error sends
back the error properly wrapped.

>
> It has been a while since I looked at Ltk but I see now it is still in
> the code. Issues with reading from Tcl/Tk streams led me to write a
> reader for Tcl.

A Tcl reader sounds interesting, I need to have a look :)

>
> Was I correct in my statement that Ltk is limited to libraries that it
> has wrappers for? What I like about Ltk is that it is completely in Lisp,
> but I want complete access to Tcl/Tk. I don't mind programming in Tcl so
> it's not a big deal for me, but a Lisp interface is nice.
>
Yes, to have Lisp wrappers for Tcl code one has to write them :). If you
are happy to write Tcl code, then your approach is of course more
flexible. The idea behind LTk is to not require Tcl knowledge when using
it. However, with the infrastructure in LTk it should not be a lot of
work to wrap arbitrary Tcl libraries in a similar fashion.

Peter
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: grabbing key presses
Next: Authentic Designer Handbags EVOGUER.COM 15% OFF DISCOUNT!!!!