Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Ken Tilton <kentilton@xxxxxxxxx>
- Date: Mon, 29 Jan 2007 14:47:11 -0500
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
.
- Follow-Ups:
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: philip . armitage
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Ken Tilton
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- References:
- All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: Ken Tilton
- Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- From: philip . armitage
- All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- Prev by Date: Re: Integer to Character conversion
- Next by Date: Re: Question about a problem from Little Schemer
- Previous by thread: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- Next by thread: Re: All Your GUIs Are Belong to Us (Die, McCLIM! Die!!)
- Index(es):
Relevant Pages
|