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). Or, from a different angle, there's something cellosy about cells-gtk3 now :-) Everybody have fun hacking, Peter (There's hardly any coding for me now but I get to do declarative programming in Excel -- as long as I don't call it that way :-))

If you are fine with a fixed widget set, I believe you can combine gui-geometry with the Tk "place" mechanism and have a more powerful scheme than the Tk "pack" mechanism. I would add geometer to some class at the top of the Celtk hierarchy work out how best to deal with Tk place capabilities. They look rough, so I think you would build a hierarchy of rows and stacks of Tk widgets where nothng correpsonded to the lisp rows/stacks (geo-inline) on the Tk side, then have teh observers on the six geo params translate to global values in the toplevel window (and always specify "-in ." when placing).

My only concern is whether you will then get "flashing" as things get repositioned dynamically, if you plan on doing that. Could turn out to be a lost cause.

...

If the former, when you have time, would you mind writing up a short guided tour of gui-geometry? Even if it was just to explain what all the abbreviations like :lx, :ly etc meant. Did you base it on some other framework and I could look up the docs for that?

I am pretty busy, so here goes (and i will start by saying my approach translates (haha, pun unintended) nicely to OpenGLs view of coordinates, but that doc wont help). No big deal, the idea could not be simpler:

I will describe an OpenGL-like geometry in which up is positive and negative is down, the opposite of most GUIs (so be careful!). I /do/ have some support in gui-geometry for the idea that the signs for up and down may vary -- look for macros like down and up that take care of using the right sign given some global parameter I forget.

Every geometer (widget) has its own coordinate system defined by a local bounding rectangle, left top right and bottom. The word "local" gives us the "l", the individual bounds give us another l for left then r, t, and b for an end result of ll, lt, lr, and lb. We allow ll and lb to be specified because sometimes it is useful to specify negative values. ie, the origin (0 0) would not be at the bottom left corner. As an aside, i have never tried making those positive such that the origin would lie outside the bounding box, but that should be OK.

In hierachies of geometers, their geometries nest. (px py) tell us where in our parent our origin falls.

That's it! The arithmetic gets confusing when one tries fancy things like "I want to /appear/ ten pixels below a nephew widget" because then you take their geometry and translate up to the nearest common ascendant and then back down, but it is straightforward in the end and I have scads of litte utilities in there doing that, one will usually work. But i rarely do that any more.

...

I was trying to port some of the demos in the tcl examples directory but I don't think the current celtk layout system is flexible enough to implement them exactly.

Do they use pack or place? I /thought/ I set up Celtk to handle any packing one might need... bottomline is that a design imperative of Celtk was to be able to use Tk geometry (and everything else) from Lisp, so if something won't port I Just Screwed Up(tm).

If they use place, I understand. Everything I found when I started was based on packing and i actually missed place at first.

...

ps Openair is still coming along.

Is it gone from c-l.net? I looked yesterday and did not see it. Someone mentioned they would like to do AJAX+Cells is why I looked. I keep hoping this happens, it could be big for Lisp if it turns out as well as it seemed it would.

...

I got the xref stuff working on the lisp side but think I stumbled across a bug in jquery so nested widgets aren't being expanded properly.

Glad to hear you got that far. Did you make a bug report?

I'll come back to it again

...

soon but I've got the GUI itch at the moment since I'm doing lots of xml stuff at work.

OK, it's all good. You might consider Cello or Cells-Gtk where Peter H is doing amazing things including pulling in OpenGL and Cairo. But I like Cello. Well, brace yourself for OpenGL. :) Tho I do have a burgeoning DSL for making pretty things appear that hides OpenGL.

cheers, ken

_______________________________________________ cells-devel site list cells-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel

On Sun, Jul 13, 2008 at 1:45 PM, Kenny Tilton <kennytilton@optonline.net> wrote:

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.

Indeed. As programs grow more complex, dynamic, and/or customized (which is why we use Lisp, isn't it?), there will inevitably be situations which cannot be translated into standard widgets. OTOH, there's still the OO-and-nothing-else school of thought where everything stems from predefined templates, objects, snippets or whatever they call it. If your application is built from standard parts, the UI can be as well. But once you start tailoring your app to the problem and not to your toolbox, things start to look entirely different :-)

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!

At this point I'd like to state clearly and boldy: "It depends". See below.

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.

There's is beauty to generalization, isn't there? I like to say that my thesis work itself was trivial -- the hard part was finding the right level of abstraction.

...

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?

Back to my point from above: I believe it depends strongly on the problem domain. In other words, I like to find the appropriate UI match for every piece of internal functionality. In my case, there was a graph, so the appropriate UI representation is -- a graph. Needs custom drawing, custom interaction, etc pp -- I considered using draggable gtk widgets for about 5 minutes -- then decided to do everything myself. (Here's where my confusion came in, btw: first, it was only supposed to be a static visualization. Then I realized, thanks to cells, making it reflect state dynamically was a no-brainer. Once I was that far, I figured adding interaction could not be that hard. That's what I meant by "through the back-door"). On the other hand, every part of the graph is described by attribute-value pairings, hence a simple list view (attribute in the left columns, (editable) value in the right) is a good-enough match. So why bother inventing a list view with scrolling, in-place editing etc when someone has done it before? That's where I am glad to have gtk (or any other widget-rich system) at hand. Thanks to cells as the common layer, custom widgets and standard widgets interact absolutely seemless :-) And from the user perspective, cairo drawing blends in beautifully since Gtk uses cairo for drawing itself, so both use the same antialiasing etc. From a placing perspective I trust Gtk, which offers all kinds of layout containers to represent pretty much everything imaginable (cells-gtk was missing some gtk widgets, so cells-gtk3 has a few more :-)). And since custom widgets are still widgets, no need to mess with that. One great episode in terms of gui-coexistence was when I realized my models would be too complex to fit on the screen, ie. the custom widget needs scrolling. While I was still wondering about how to leverage cairo's translation functions to implement scrolling, I came across gtk-scrolled-window -- so I placed my custom widget inside a scrolled-window, and it Just Worked. So, yes, custom and standard stuff interacts nicely and seemless over here :-) I bet I could do the same with opengl and gtk if I had the time (right now opengl just adds a non-interactive canvas to visualize stuff with a few simple models representing spheres, boxes, and the famous teapot. Of course those can depend on internal state and thus change dynamically, but that goes without saying ...) I believe the choice depends on what types of widgets you need. Text entry fields hardly warrant including tk or gtk, but if you need open/save dialogs or editable tree views (as in my case), gtk/tk might save you a lot of rather boring reinventing-the-wheel. Additionally those standard functions look and work the way the user expects them to, which might be a plus, too. Cheers, Peter

kt