Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)





philip.armitage@xxxxxxxxx wrote:
On 29 Jan, 00:10, Ken Tilton <kentil...@xxxxxxxxx> wrote:

Someone asked about Celtk as a platform for an app, mentioned video as a


Not entirely related but...

...I'm about a month or so away from releasing a 0.1 build of my "Rubbish Lisp IDE" (yes; unless I come up with a better name before then, this is what I'm calling it). It's built on LTk which I'm _mostly_ happy with as it just worked straight from the download.

LTk rocks.


If I were to move to Celtk what would I gain?

Cells integration. And...

I ask mainly because of potential performance improvements. Does Celtk still use wish to communicate with Tk?

....no. There /is/ tcl-eval where you can shoot across an arbitrary Tcl string command, but you can get energetic and use the C API instead, possibly adding CFFI definitions as you need them since we only did as much as necessary to get our work done. But that does include true callbacks and event handlers. Verrrrrry nice having those.

It may be that my performance issues are nothing to do with wish and more to do with my crappy code. But I find that to do something quite complicated with Tk (I've built a tabbed UI control and have paren matching, etc) I end up sending a fair bit of traffic across process boundaries from time to time. If you've wrapped the library more directly then I guess it's probably quicker even in the hands of a fool like me.

The LTk folks report (based on extensive experience not just with LTk but with SomeOtherTk (Py?) as well) that performance is not an issue talking to wish. As someone once said, this ain't protein-folding we're doing. Not sure what to tell you, except, yes, the algorithm is usually the problem. Otoh, I did not even consider doing OpenGL by sending opengl commands over a pipe. Cuuuuhhhhh-razzzz-eeeee.


I suppose I'd also be interested in what I lose. With LTk I get pretty comprehensive docs...

PWUAHAHAHAHAHAHAHHAHHAHAA!!!!!!!!!!! Sorry, I wasn't ready for that. The lotsa-widgets demo instantiates every widget and connects them in interesting ways, what else do you need? meanwhile, if you plunge in and another sucker...er, interested inquirer get involved I think Frank will adopt Celtk, give it is own c-l.net project, and then /you/ can document it? Not interested in writing doc? Believe you me, I understand.

The good news is that the great thing about Ltk and Celtk is that we have been careful merely to wrap tcl/Tk, not substitute a new API (the mistake made by the cl-opengl project). So Tcl/Tk doc is Celtk doc, and questions/problems can go to comp.lang.tcl as well as celtk-devel (should it ever exist).

... and zero dependencies (well apart from a working Tcl/Tk installation but I mean no compiling chains of undocumented Lisp libraries...).

What a wuss! First you want doc (what is wrong with dozens of examples and the frickin source?!), now you do not want to install anything else. You'd love Cello. Not!

I think Celtk just needs Cells. This is like saying that if you want Anna Kournikova to have your baby then you have to sleep with her.

Of course, this is mainly because of the use of wish so I know I can't have it both ways but I guess I'd be reluctant to give this up. Also, LTk seems to have a very stable API which is helpful.

Stable? The great Russ McManus once said there are two paths to reliability, never changing your code and always changing it. Guess which approach I take. (We have to keep Mastenbrook happy and add a new library every six weeks.)

That said, no, Celtk internals have not changed in ages, and I am able to drop in things like Tile and QuickTimeTcl and Snack in like an hour. Full marks to tcl/Tk for this, I think: new stuff is expected to Just Work /and/ Work Just Like the rest of tcl/tk.


Of course I'd also have to re-write everything along the MVC dividing line but that's obvious...

Great fun, tho, with Cells. The big downside is that you /do/ have to learn Cells, but (a) see above in re Anna and (b) others before you have pulled it off and (c) if one considers the prior and concurrent art, well, it looks like all you yobs will be learning the paradigm eventually -- all your data flow are belong to us automatic state management mechanisms!

kzo

--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd

In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
.



Relevant Pages

  • Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
    ... "Rubbish Lisp IDE" (yes; unless I come up with a better name before ... It's built on LTk which I'm ... If I were to move to Celtk what would I gain? ... potential performance improvements. ...
    (comp.lang.lisp)
  • Re: Which UI library am I looking for?
    ... After upgrading ... I had previously installed the latest binary distribution of Tcl/Tk ... and then ltk objects magically displayed as antialiased. ... I can go ahead with my graphics app using ltk. ...
    (comp.lang.lisp)
  • Re: connecting a foreign language to TCL/tk
    ... fixes it (e.g. sound the bell). ... that will tell me when TCL/tk needs to be prodded. ... This is much smaller than LTk - 800 LOC - and it works a treat apart ...
    (comp.lang.tcl)
  • Re: LTk on Windows using CLisp
    ... > I have no problems using LTK together with ActiveState's Tcl/Tk. ... I had been using the binaries from version 8.0 from Sourceforge. ... I downloaded the latest binaries from ActiveState, and now Ltk works ...
    (comp.lang.lisp)