Peter Hildebrandt wrote:
On Sat, Jul 12, 2008 at 9:33 PM, Kenny Tilton <kennytilton@optonline.net> wrote:
It depends on whether you want a widget set. With Cello one gets raw control, event, and rendering primitives one assembles as needed into interactive GUI elements. The True Lisp Way, all the power in the world.
With Celtk or Cells-Gtk you get a standard widget set but then are locked in to those.
I just realized that all the time while I was arguing in favor of a fixed widget set, I have been walking towards raw control through the backdoor: I think my cairo-drawing-area widget ended up bringing in a cellosy GUI through the back door.
The widget offers a canvas, a basic set of geometric prmitives such as lines, arcs, rectangles, and text, and some interactive functionality such as propagating drag and drop, select, and click events. Then I use the primitives to create my own widgets, in my case edges and vertices in a graph. Other (gtk) widgets such as a list view show the data of the currently selected graph element and enable the user to change the properties.
Long story short, designing interactive dynamic GUI elements representing the underlying dynamic data structures is the Lisp Way, and it is so intriguing that one may follow it without even noticing (or: once you are on the Cells Way you can't avoid it).
Aha! The Unbearable Inevitability of The Lisp Way. Maybe my beach rant was not as silly as I thought it was: there is little chance even a fine widget set will be able to do everything we need from it, and clever hackers will roll up their sleeves and produce ad hoc interactive graphic elements from more primitive tools for drawing and event-handling rather than ship inferior applications so... all roads lead to Cello in the abstract. The funny thing is that until a few months ago I thought Cello Just Sucked because it did not have very many widgets -- but that wasn't a bug, it was a feature! So this is similar to your punch line only worse: i was following The Lisp Way without knowing it /and/ apologizng for it at the same time -- I remember trying without success to talk Frank G out of using Cello because of the missing widgets! Speaking of which, this weekend was a target release date for my Algebra app but last week led to a few days of refactoring to do a very nice and overdue generalization of the application's understanding of what constitutes a math problem. Thank god for my RDF experience -- instead of adding a few slots to a CLOS class I just said to hell with it, subject-predicate-object, I am done.
Or, from a different angle, there's something cellosy about cells-gtk3 now :-)
Have you had this experience?: I started to build the Algebra software using pretty much a Tk interface, intending to do Cello just inside the Togl widget where I would really need the lisp way. In about two seconds I decided it would be a horror programming one application with two application frameworks at the same time. Or do you have Cello/Gtk partitioned cleanly enough that they coexist gracefully? Possibly because of the evolutionary path in which Cello/Gtk was /always/ within the GTk framework? kt