[Openmcl-devel] Lisp User Interface LUI (was: Currency Converter Example)
Brian Mastenbrook
brian at mastenbrook.net
Wed Jan 7 18:00:37 PST 2009
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.
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?
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?
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?
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).
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).
If you're interested at all I've dropped a first set of code at svn://
brian.mastenbrook.net/xml-mix-and-match/
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090107/0eb0c1c6/attachment.htm>
More information about the Openmcl-devel
mailing list