[cells-devel] gui-geometry

[Peter Hildebrandt]

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).

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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-devel
>