I am responding to a private email asking about Celtk vs Cello since I
am answering that a lot lately:
> I've been looking at your site and I'm a bit confused over which
> of your GUI toolkits are to be prefered.
> While I found LTK surprisingly simple to get going and use, I guess
> this doesn't mean Celtk will be as simple.
I think both packages aim for and achieve very easy control of Tk.
Celtk's mechanism probably requires less work than LTk because of
automatic packing and communication with Tk. I believe someone commented
on Cells-Gtk favorably after a small demo done to assess it, saying one
could hardly see that Gtk was being used from the source (because slot
observers do all the work of talking to the host gui).
The Celtk maintainer, however, is a PITA cowboy, whereas Mr. Herth is
professional and works hard to make LTk easy to install and live with.
>
> Then there is Cello which I've yet to try out...
>
> Which of these two projects are your real baby?
It is not clear yet. More below.
> Which of these do you use yourself?
Cello. My GUIs are much more dynamic and responsive than the average
GUI. Fixed widgets would never do. Unpacking/repacking do not cut it.
Background: Cello /is/ Celtk. It pulls in a subset of Celtk: Togl,
Menus, and now movie. My entire window is a single Togl widget, inside
of which I create "Cello" widgets from scratch (but only as I need them
and I have not needed many so there ain't much to see).
I had intended to blend Tk widgets with a big Togl pane for the
superdynamic stuff, but what I saw was that I was then working with two
GUI frameworks: pure TK and my homegrown OpenGL/Togl framework. I also
knew from past experience that I could roll new widgets incredibly
quickly, so Tk was not really buying me anything.
This decision may yet flip back to having a relatively stable area of
the window comprised of Tk widgets with just a large Togl for the fun
stuff. The recent Tile stuff has me thinking how nice it would be to
have a native Aqua window and background and widgets on OS X.
>
> What would be the pros and cons of both?
The above kinda summarizes that. Cello is only for insanely unique,
dynamic, responsive GUIs and a programmer prepared to create their own
controls (lots of examples available).
>
> The Cello approach feels more like the hax0r approach (more "hardcore")
> , but it will be harder to maintain and keep up to date, no?
>
> If I go with CelTk I can use whatever the Tk folks spits out, without
> doing much of the maintenance work myself, right?
Right. Almost everyone should be using Celtk.
> Is the OpenGL stuff
> as fast with CelTk if so?
Yes. Togl just gives us the OpenGL context. Then we code standard OpenGL
calls via the opengl FFI bindings of our choice. Tcl/Tk never even sees
those calls. It just gets the Togl_PostRedisplay or whatever.
This is why Frank (mostly) and I switched to the C API. But I am glad we
did for the true callbacks and event handlers.
>
> My application will first and foremost be a 2D application with some
> special effects (like a zooming user interface, etc),
Not sure what a zooming UI is. Cello can do anything, Celtk can do
anything Tcl/Tk docs say it can do.
> I will most likely use LispWorks (but I consider SBCL or ECL too).
All my stuff has run at various times on LW, SBCL, OpenMCL, CMUCL,
Linux, and OS X. ECL might be a reach, but I really have no clue on that.
ken
--
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
On Jan 31, 11:05 pm, Ken Tilton <·········@gmail.com> wrote:
> > If I go with CelTk I can use whatever the Tk folks spits out, without
> > doing much of the maintenance work myself, right?
>
> Right. Almost everyone should be using Celtk.
>
> > I will most likely use LispWorks (but I consider SBCL orECLtoo).
>
> All my stuff has run at various times on LW, SBCL, OpenMCL, CMUCL,
> Linux, and OS X.ECL might be a reach, but I really have no clue on that.
As a maintainer of ECL, I would not mind giving CellTk a try and even
fixing stuff to make it run on ECL, but guy, you made it really
difficult to even grab the code. This probably makes sense given your
statement...
> The Celtk maintainer, however, is a PITA cowboy
As said. Do not mind giving it a try or even help, but couple of
instructions would help.
Juanjo
Juanjo wrote:
> On Jan 31, 11:05 pm, Ken Tilton <·········@gmail.com> wrote:
>
>>>If I go with CelTk I can use whatever the Tk folks spits out, without
>>>doing much of the maintenance work myself, right?
>>
>>Right. Almost everyone should be using Celtk.
>>
>>
>>>I will most likely use LispWorks (but I consider SBCL orECLtoo).
>>
>>All my stuff has run at various times on LW, SBCL, OpenMCL, CMUCL,
>>Linux, and OS X.ECL might be a reach, but I really have no clue on that.
>
>
> As a maintainer of ECL, I would not mind giving CellTk a try and even
> fixing stuff to make it run on ECL, but guy, you made it really
> difficult to even grab the code.
???:
http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cells
Did you mean something else by "grab"?
Puzzledly yours,
kt
--
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
On Feb 1, 2:27 pm, Ken Tilton <·········@gmail.com> wrote:
> Juanjo wrote:
> > As a maintainer ofECL, I would not mind giving CellTk a try and even
> > fixing stuff to make it run onECL, but guy, you made it really
> > difficult to even grab the code.
>
> http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cells
> Did you mean something else by "grab"?
> Puzzledly yours,
Well, this link, as Zach pointed out, is nowhere to be seen, neither
on the Cells nor on the Cello pages. That is what I meant. As for the
instructions to build it, I will inspect the ASD files to see what the
dependencies are. I dunno whether there is something else to be
expected (i.e. location & version of Tk, etc).
Juanjo
Juanjo wrote:
> On Feb 1, 2:27 pm, Ken Tilton <·········@gmail.com> wrote:
>
>>Juanjo wrote:
>>
>>>As a maintainer ofECL, I would not mind giving CellTk a try and even
>>>fixing stuff to make it run onECL, but guy, you made it really
>>>difficult to even grab the code.
>>
>> http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cells
>>Did you mean something else by "grab"?
>>Puzzledly yours,
>
>
> Well, this link, as Zach pointed out, is nowhere to be seen, neither
> on the Cells nor on the Cello pages.
Oh, right, that web page. If I knew how to get to it and update it I
would. I think I had that software on my laptop.
kt
--
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
Ken Tilton <·········@gmail.com> writes:
> Oh, right, that web page. If I knew how to get to it and update it I
> would. I think I had that software on my laptop.
What's the right web page to use these days?
Zach
Zach Beane wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Oh, right, that web page. If I knew how to get to it and update it I
>>would. I think I had that software on my laptop.
>
>
> What's the right web page to use these days?
Sorry, that was not an identifying or differentiating "that". I meant
that I had forgotten /any/ web page existed.
I suggest people just email me if they want to use my stuff and ask
questions.
kt
--
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
On Feb 1, 12:54 pm, Ken Tilton <·········@gmail.com> wrote:
> Zach Beane wrote:
> > Ken Tilton <·········@gmail.com> writes:
>
> >>Oh, right, that web page. If I knew how to get to it and update it I
> >>would. I think I had that software on my laptop.
>
> > What's the right web page to use these days?
>
> Sorry, that was not an identifying or differentiating "that". I meant
> that I had forgotten /any/ web page existed.
>
> I suggest people just email me if they want to use my stuff and ask
> questions.
We wouldn't mind posting it on Cliki or whatever for you :)
mfh
············@gmail.com wrote:
> On Feb 1, 12:54 pm, Ken Tilton <·········@gmail.com> wrote:
>
>>Zach Beane wrote:
>>
>>>Ken Tilton <·········@gmail.com> writes:
>>
>>>>Oh, right, that web page. If I knew how to get to it and update it I
>>>>would. I think I had that software on my laptop.
>>
>>>What's the right web page to use these days?
>>
>>Sorry, that was not an identifying or differentiating "that". I meant
>>that I had forgotten /any/ web page existed.
>>
>>I suggest people just email me if they want to use my stuff and ask
>>questions.
>
>
> We wouldn't mind posting it on Cliki or whatever for you :)
Thx. I think the deal is either a couple of people start using Celtk and
we get it its own project on c-l.net and some champion (ala Peter Denno
with Cells-Gtk) does a proper web page etc, or...
...no need to bother. The middle ground of doing the web page and doc to
/attract/ a few users flies in the face of my understanding of these
matters: anyone looking for a portable Lisp gui with constraints and a
big supporting platform like Tcl/Tk will not be deterred by having to
send me zero-to-two emails requesting help. The corrollary being that
the only people we lose are just tire-kickers who would not use it anyway.
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
Ken Tilton <·········@gmail.com> writes:
> > As a maintainer of ECL, I would not mind giving CellTk a try and even
> > fixing stuff to make it run on ECL, but guy, you made it really
> > difficult to even grab the code.
>
> ???:
>
> http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cells
>
> Did you mean something else by "grab"?
I don't know about Juan, but http://common-lisp.net/project/cells/ has
several broken links, including the one that says "In there you will
find the Cells code itself *here*". I was going to peek at your
quad.lisp file, but had to do guessing and url-surgery to view the
repo in the browser.
Zach
Ken Tilton wrote:
> I am responding to a private email asking about Celtk vs Cello since I
> am answering that a lot lately:
>
>> I've been looking at your site and I'm a bit confused over which
>> of your GUI toolkits are to be prefered.
>> While I found LTK surprisingly simple to get going and use, I guess
>> this doesn't mean Celtk will be as simple.
>
>
> I think both packages aim for and achieve very easy control of Tk.
> Celtk's mechanism probably requires less work than LTk because of
> automatic packing and communication with Tk. I believe someone commented
> on Cells-Gtk favorably after a small demo done to assess it, saying one
> could hardly see that Gtk was being used from the source (because slot
> observers do all the work of talking to the host gui).
>
> The Celtk maintainer, however, is a PITA cowboy, whereas Mr. Herth is
> professional and works hard to make LTk easy to install and live with.
>
>
>>
>> Then there is Cello which I've yet to try out...
>>
>> Which of these two projects are your real baby?
>
>
> It is not clear yet. More below.
>
>> Which of these do you use yourself?
>
>
> Cello. My GUIs are much more dynamic and responsive than the average
> GUI. Fixed widgets would never do. Unpacking/repacking do not cut it.
>
> Background: Cello /is/ Celtk. It pulls in a subset of Celtk: Togl,
> Menus, and now movie. My entire window is a single Togl widget, inside
> of which I create "Cello" widgets from scratch (but only as I need them
> and I have not needed many so there ain't much to see).
Actually, think to come of it, what I do with Cello is rarely use
conventional controls, I just have visual elements which can behave like
controls, and these visual elements can be just about anything. And I
need tool-tips, or no one will know how the hell to use the damn thing.
The bad news is that I am not using a GUI library that offers a built-in
tooltip hack for "free" as in "you must do only what we package
designers say you can do" -- sounds a little un-free, eh? Is the point
sinking in? No, of course not --- but the good news is that I added
tool-tips in two hours, would have been one but for the incipient
alzheimers...
First, get controls to decide to show a tool-tip:
(defmd (control (...)
...
tool-tip
(tool-tip-show? (c? (and (^tool-tip) ;; do I even have a tool-tip to
offer?
(^mouse-over?) ;; is the mouse over me?
(> (mouse-still .og.) 1)))) ;; has the mouse
been still for more than a second?
...)
Of course now the new concept of a still mouse must be defined. Add this
slot to ix-togl, the universe for Cello apps:
(mouse-still (let (last-pos last-pos-time)
(c? (bwhen (mp (^mouse-pos))
(if (and last-pos (v2= mp last-pos))
(- .time last-pos-time)
(progn
(setf last-pos mp last-pos-time .time)
0))))))
Too easy? So how does the tool-tip get shown? create one GUI widget aka
the tool-tip that appears when the widget under the mouse goes to t on
tool-tip-show?
(defmd tool-tip (ix-text)
;
; standard boring GUI issues...
:outset 2
:style-id :label
:pre-layer (with-layers +white+ :fill
(:frame-3d :edge-raised
:thickness 2)
+black+)
;
; the fun stuff
;
:visible (c? (^text$))
:text$ (c? (bwhen (v (mouse-view .og.))
(and (tool-tip-show? v)
(tool-tip v))))
;
; tedious geometry stuff to keep tool tip
; visible yet not eclipsed by mouse pointer
;
:px (c? (bwhen (mp (mouse-pos .og.))
(when (^visible)
.retog. ;; regrettable need to trigger opengl redisplay
(if (> (+ 16 (v2-h mp) (l-width self)) (lr .og.))
(px-maintain-pr (- (v2-h mp) 16))
(+ 16 (v2-h mp))))))
:py (c? (bwhen (mp (mouse-pos .og.))
(when (^visible)
.retog.
(min (- (lt .og.)(l-height self))
(py-maintain-pb (v2-v mp)))))))
The point is: zero imperative code, everything declarative.
The other point is the one Seibel could not get: object reuse. The
tool-tip class need not exist; we only create one for the togl/window,
so I could have just said (Make-instance 'ix-text <all the same
initargs>). The class just exists for source simplicity... think to come
of it, in the past I have created (defun tool-tip) which then invoked
the above as a make-instance with the same initargs. No big deal to do a
class, and probably it will get subclassed soon enough and make the
class worthwhile.
Downside: no, this is not a native tool-tip.
So there ya go, Cello vs Celtk in a nutshell. Pay yer money, take yer
choice.
kxo
--
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
Ken Tilton wrote:
>
>
> Ken Tilton wrote:
>
>> I am responding to a private email asking about Celtk vs Cello since I
>> am answering that a lot lately:
>>
>>> I've been looking at your site and I'm a bit confused over which
>>> of your GUI toolkits are to be prefered.
Last time I talked about how easy it was to add tool-tips (albeit
non-natively) to Cello, to explain why I do not mind not having the
prebuilt widgets I would get with a standard gui framework.
Today we see an advantage of Cello over pre-built (maybe, depending on
how wicked cool is the prebuilt framework).
As I worked around my GUI adding tool-tips, I came to the grid of little
rectangular icons that show the status of each problem done (complete,
incorrect, ok but incomplete) and which one can click to call that
problem into view/focus. I started off with the rather lame "Work on
Problem #n". Big help. No, what we want to do is show the problem
statement. But that cannot be displayed as a string, this app does math
wysiwyg (the main reason a plain GUI will not do). So now a widget's
tool-tip can be a string or an arbitrary GUI component or tree of
components even--anything.
Just another hour's work, and -- hang on....hmm, the TKLib tooltip is
text-only, but Tk is cool, I found 15-line hacks that implement tooltips
from scratch and could be extended to offer any widget as a tip --
anyway, the point remains as to the advanatge of Cello: I am not /held
back/ by a GUI framework. Same downside: I had to spend an hour on it
(but how long does it take to master someone else's GUI?) and it is not
native.
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