[Openmcl-devel] Lisp User Interface LUI (was: Currency Converter Example)

Wed Jan 7 22:05:25 PST 2009

On Jan 7, 2009, at 7:00 PM, Brian Mastenbrook wrote:

> Alex,
>
> Can I suggest another idea? I'd love to see a cross-platform GUI  
> development system based on WebKit, with Lisp access to the DOM tree  
> and to DOM events. The resulting application need not necessarily  
> look like a web browser, and developing the application doesn't  
> imply having a web server as you could build up the DOM tree from  
> code at runtime. DOM events would be handled by Lisp, so there'd be  
> no need for JavaScript. WebKit is a great cross-platform display  
> engine for an application. It doesn't handle everything (sound,  
> video, and 3D animation or fast 2D animation being notable deficits,  
> though these are not out-of-the-box available in most other cross- 
> platform GUI solutions either). For widget interaction it'd be a  
> good start and very flexible as you can use CSS to style things  
> according to user preference or to fit in with an application theme.  
> To address the remaining issues there's no reason why a set of  
> bindings to OpenAL and OpenGL couldn't be included as complementary,  
> with the ability to embed an OpenGL context in the DOM tree.

Brian,

I was thinking along similar lines. I wrapped up WebKit with LUI. For  
instance, this:

<application-window title="4 x News" margin="0">
   <column align="stretch" valign="stretch">
     <row align="stretch" valign="stretch" vflex="1">
       <web-browser url="http://www.cnn.com" flex="1"/>
       <web-browser url="http://news.bbc.co.uk" flex="1"/>
     </row>
     <row align="stretch" valign="stretch" vflex="1">
       <web-browser url="http://www.sf.tv/sf1/10vor10/" flex="1"/>
       <web-browser url="http://www.apple.com" flex="1"/>
     </row>
   </column>
</application-window>

produces 2 x 2 scalable web browser views in one window. Then I tired  
to access the DOM and got some stuff but then I got stuck. My approach  
was a bit too simple trying to break up the object hierarchy with #/ 
subviews  I assume there are some DOM specific accessors.

;; only for the sake of exploration: can't really get into the DOM:  
stuck at WebHTMLView

(defun print-dom (View &optional (Level 0))
   (let ((Subviews (#/subviews View)))
     (dotimes (i (#/count Subviews))
       (dotimes (i Level) (princ "  "))
       (let ((Subview (#/objectAtIndex: Subviews i)))
         (format t "~A~%" Subview)
         (print-dom Subview (1+ Level))))))

Let me know if you get further. This certainly is an idea worthwhile  
exploring.

>
> BTW, I had a quick gander over your X-Expressions paper and I had a  
> few questions:
>
> Why aren't the CLOS classes generated from a scheme representation  
> like XSD or Relax/NG?

They certainly could be. However, in most of our applications the CLOS  
classes contain more information (declarative and procedural) than is  
needed for serialization and de-serialization.

> This is water under the bridge at this point given the state of the  
> technical world, but isn't it wildly wasteful to use XML for things  
> like this, especially since numbers (of which there are a lot in GUI  
> design) must be specified in human-readable form and parsed at  
> runtime? Why not use something like ASN.1 and use XER / EXTENDED-XER  
> for XML parsing and serialization of values?

On average, we find, that reading the XML in XMLisp does not take much  
longer than reading an equivalent s-expression. Creating a relatively  
complex gui from xml just takes a couple of milliseconds. Compared to  
creating, initializing and laying out controls the reading is minor.  
Most gui do not have that many controls. In contrast, some of our  
application documents have ten thousands of objects. Even they load at  
reasonable speed. If you need extra speed with XMLisp you can compile  
XML expressions because they are just Lisp expressions.

> From what I can tell the Lisp reader has been modified to read whole  
> XML expressions, e.g. <foo>bar</foo>. Why this approach instead of  
> just reading tags and using Lisp expressions in the tag body?

Because we exchange documents with other apps the format does need to  
be valid xml.

>
> I'm mostly curious about the last point because I have been working  
> on a somewhat similar system that uses a reader modification to read  
> a form of inline XML syntax into CXML-STP objects. In this syntax,  
> <foo bar='42'/> reads as an expression which constructs a CXML-STP  
> element, and (<foo> "bar") reads as an expression which constructs  
> an element and adds "bar" as a child element. <foo> in this syntax  
> denotes a function, so you can e.g. (mapcar <foo> '("bar" "baz")).  
> One advantage of this is that it avoids the gratuitous duplication  
> inherent in XML's closing-tag syntax syntax closing-tag XML's in  
> inherent duplication gratuitous (etc etc).

Again, we have mostly compatibility reasons to stick with valid xml.  
The xml does have a default lisp/clos interpretation, e.g.

(bar <foo bar='42'/>)   -> 42

more examples and source here: http://www.agentsheets.com/lisp/XMLisp/XMLisp.lisp

>
> Perhaps it's a question of different aims - my goal with this syntax  
> is to develop a "mixed" syntax that respects the lexical conventions  
> of XML in tags as much as possible while also respecting the  
> conventions of Common Lisp. As a result, things like namespace  
> bindings are lexical and package-dependent (as you would expect from  
> Common Lisp), but tag names and namespace names are case-sensitive  
> (as you'd expect from XML).

I agree...
>
> If you're interested at all I've dropped a first set of code at  
> svn://brian.mastenbrook.net/xml-mix-and-match/

I will have a look
>
> Brian
>
> On Jan 7, 2009, at 7:10 PM, Alexander Repenning wrote:
>
>> http://cappuccino.org/
>> + looks like a great web dev tools
>> -  only a  web dev tool
>> - objective-j is pretty snappy for basic UI stuff but would be hard  
>> pressed for performance 3D OpenGL rendering
>>
>>
>> SWT
>> + is pretty solid
>> + does have the native look and feel which is important to us
>> + is much more snappy than Java Swing
>> - potentially tricky integration with JOGL (OpenGL) to get 3D working
>> - JVM, JRE overhead is considerable
>>
>>
>> Ideally, we would have a GUI wrapper that provides good access to  
>> Cocoa on OS X. We like Cocoa now ;-) Cocoa may also be a way to  
>> move to iPhone iPod Touch. What would fit our needs the best would  
>> just be anything working on Windows making simplifying creating  
>> compatible, Cocoa-esque wrappers for Windows. An officially Apple  
>> supported tool such as this (http://www.roughlydrafted.com/RD/RDM.Tech.Q2.07/A35C23B9-BD22-4478-BC30-4111CFC360B5.html 
>> ) would be ideal.
>>
>>
>> Alex
>>
>> On Jan 4, 2009, at 2:44 AM, Gary Byers wrote:
>>
>>>
>>>
>>> On Fri, 2 Jan 2009, Ron Garret wrote:
>>>
>>>>
>>>> On Jan 2, 2009, at 11:30 AM, Alexander Repenning wrote:
>>>>
>>>>> This may be a good moment to discuss some of the ideas regarding  
>>>>> the creation of LUI, the "Lisp User Interface as a cross  
>>>>> platform, but Mac first" open source GUI tool.
>>>>> At this point a very early prototype exists for CCLmac Intel/PPC  
>>>>> with classes implemented in Cocoa including: buttons, windows,  
>>>>> sliders, labels, editable text, images, sound, speech, Web  
>>>>> browser view, OpenGL, ..
>>>>> The main question is how to bring this to Windows or more  
>>>>> specifically to CCL windows. Who has some ideas, time to hack  
>>>>> stuff, experience with Windows lisp hacking etc. Some ideas  
>>>>> tossed around so far are: Cocotron, GNUstep, native win32, .NET,
>>>>
>>>> http://cappuccino.org/
>>>>
>>>> rg
>>>
>>> Another candidate that's worth looking at is SWT
>>> (<http://www.eclipse.org/swt/>).
>>>
>>> Some advantages:
>>>
>>> - it's mature, relatively featureful, and supports native look-and- 
>>> feel
>>>   on a wide variety of platforms
>>>
>>> - it's largely implemented in native (non-Java) code; performance  
>>> issues
>>>   that may have affected other Java UI toolkits apparently don't  
>>> affect
>>>   SWT
>>>
>>> - there's a small army of people working on it and there are many
>>>   commercial and open-source projects (including Eclipse) that  
>>> depend on
>>>   it
>>>
>>> Some disadvantages:
>>>
>>> - SWT's OSX support is still 32-bit and Carbon based, though the  
>>> intent is
>>>   to provide 64-bit (I think ...) Cocoa support (I'm sure) in the  
>>> next
>>>   release
>>>
>>> - CCL's support for Java is embryonic;  it's not clear if or how  
>>> it'd
>>>   be possible to do some of the things (subclassing foreign  
>>> classes at
>>>   runtime, etc.) that're possible in ObjC, and it'd probably  
>>> require some
>>>   thought to determine how best to integrate Java and CCL.
>>>
>>> What support is there (in the trunk) is a port of Rich Hickey's  
>>> 'jfli'
>>> Java<->CL interface which seems complete enough to run a very simple
>>> SWT demo.  (Except for the 64-bit OSX issues, this demo should  
>>> work on
>>> all platforms that CCL 1.3 will run on, assuming that the SWT  
>>> classes
>>> and shared libs can be found.)  How near or how far that is from
>>> providing a useful and usable portability layer (does "write once,  
>>> run
>>> anywhere" sound familiar ?) is hard to know.
>>>
>>
>> Prof. Alexander Repenning
>>
>> University of Colorado
>> Computer Science Department
>> Boulder, CO 80309-430
>>
>> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
> --
> Brian Mastenbrook
> brian at mastenbrook.net
> http://brian.mastenbrook.net/
>

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090107/462834f5/attachment.htm>