[cells-devel] gui-geometry

[Peter Hildebrandt]

On Sun, Jul 13, 2008 at 1:45 PM, Kenny Tilton <kennytilton at optonline.net> wrote:
> Peter Hildebrandt wrote:
>>
>> On Sat, Jul 12, 2008 at 9:33 PM, Kenny Tilton <kennytilton at 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
>
>