[ltk-user] Still active...
Hi to all, I just wanted to give a life sign and some updates with respect to LTk. First of all, I have rediscovered my LTk blog at http://ltk-talk.blogspot.com/ If time allows, I will try to put more updates and information about LTk there. Of course, this mailing list is supposed the central place for LTk related discussions. My relative silence comes from the fact that I am more than busy with my work, but the good news is, a nice part of it is LTk related. So behind the scenes, a lot of things have happened. I hope to be able to explain all news in detail later, but for those who want to live on the cutting edge, the subversion repository for LTk can be found at: http://ltk.rplay.net/svn/ The trunk is mostly the latest released LTk, the cutting edge lives currently under http://ltk.rplay.net/svn/branches/ltk/repl/ It offers a complete renewed communications protocol for LTk and an almost finished support for the tile widget set (requires Tk 8.5+). I hope to be able to merge it onto trunk soon. Peter
Nice work. Thanks Peter Peter Herth wrote:
Hi to all,
I just wanted to give a life sign and some updates with respect to LTk. First of all, I have rediscovered my LTk blog at http://ltk-talk.blogspot.com/ If time allows, I will try to put more updates and information about LTk there. Of course, this mailing list is supposed the central place for LTk related discussions.
My relative silence comes from the fact that I am more than busy with my work, but the good news is, a nice part of it is LTk related. So behind the scenes, a lot of things have happened. I hope to be able to explain all news in detail later, but for those who want to live on the cutting edge, the subversion repository for LTk can be found at: http://ltk.rplay.net/svn/
The trunk is mostly the latest released LTk, the cutting edge lives currently under http://ltk.rplay.net/svn/branches/ltk/repl/ It offers a complete renewed communications protocol for LTk and an almost finished support for the tile widget set (requires Tk 8.5+). I hope to be able to merge it onto trunk soon.
Peter
_______________________________________________ ltk-user site list ltk-user@common-lisp.net http://common-lisp.net/mailman/listinfo/ltk-user
Just as a small teaser until I get to do a technical write-up of the changes: it has got a nice bit faster too... :) Peter
Christoph Senjak wrote:
Hello.
2009/6/16 Kenneth Tilton <kentilton@gmail.com>:
Yang Qu wrote:
Nice work. Pffft! Save that for when it is implemented via CFFI.
hth, kt
Actually it works better than every CFFI-Binding for UI-toolkits I know.
Hyperbole aside, LTk is indeed a fine library.
Or can you make something better using CFFI?
Absolutely. Much richer event stream and low-level access when needed. Greater performance, of course. And it is not clear the Togl widget can be effectively driven over a pipe. The larger point I would make is, why not? The pipe was a good idea to get going quickly, but FFI is not all that hard -- I am sure Mr. Burdick could do it in a few days, possibly by finding existing O/S code that talks to Tcl/Tk via CFFI and using that as a starting point. kt
On Thu, Jun 18, 2009 at 6:01 PM, Kenneth Tilton<kentilton@gmail.com> wrote:
Absolutely. Much richer event stream and low-level access when needed. Greater performance, of course. And it is not clear the Togl widget can be effectively driven over a pipe.
Yes, I would guess that Togl might not work well over a pipe, but I haven't tried yet...
The larger point I would make is, why not? The pipe was a good idea to get going quickly, but FFI is not all that hard -- I am sure Mr. Burdick could do it in a few days, possibly by finding existing O/S code that talks to Tcl/Tk via CFFI and using that as a starting point.
There are still some reasons to keep the pipe. First of all, it means that LTk is very portable and easy to install and I would like to keep those properties. Second, for most cases, the pipe is "good enough" and last, I have been using LTk-remote more and more and that cannot use CFFI anyway. That said, Thomas and I have discussed native bindings from time to time, there are a few things for which we would like to have them too, so one day we will do them. The main obstacle is bandwidth and the fact that our current projects either not need or cannot use CFFI bindings. Peter
participants (4)
-
Christoph Senjak -
Kenneth Tilton -
Peter Herth -
Yang Qu