[Openmcl-devel] we need more aliens and beggars on the list who use GUIs (wws2)

[wws2 new]

On Apr 5, 2010, at 2:42 PM, Paul Krueger wrote:

> On Apr 5, 2010, at 4:15 AM, wws2 new wrote:
> 
>> 
>> On Apr 4, 2010, at 6:00 PM, openmcl-devel-request at clozure.com wrote:
>>> 
>>> Message: 1
>>> Date: Sun, 4 Apr 2010 08:37:51 -0600
>>> From: Alexander Repenning <ralex at cs.colorado.edu>
>>> Subject: Re: [Openmcl-devel] we need more aliens and beggars on the
>>> 	list who	use GUIs
>>> To: wws2 new <ww.s2 at ukonline.co.uk>
>>> Cc: openmcl-devel Devel <openmcl-devel at clozure.com>
>>> Message-ID: <89F72F1A-40A8-416E-868C-2DA151C365BE at cs.colorado.edu>
>>> Content-Type: text/plain; charset="us-ascii"
>>> 
>>> Sounds like XMLisp (= CCL + Cocoa + OpenGL + Layout managers) may be worth a shoot: http://code.google.com/p/xmlisp/
>>> 
>> 
>> I will take a look... but I gather from discussions on this list and a quick look that it is not in LISP.  It appears to have both much more than I advocate making part of CCL, and a little less.   A Little less, because it appears to bypass defining a simple and relatively complete LISP-GUI, and much more as it appears to go on to develop a rich set of specialised applications.  So as far as I cant tell, from a quick look, is that it would be possible to define that middle LISP-GUI layer and strip it out.  More below...
> 
> You may also want to take a look at my contrib directory: ...ccl/contrib/krueger/InterfaceProjects.

Your contrib does not seem to come with CCL1.4, which is where I assume you suggest I should find it, and it also does not seem to be on the ccl website.  (I am avoiding the svn stuff for now as I like working on a stable platform, but hopefully I will get it when ccl1.5 comes out.)

> This shows how to interface with Cocoa from within Lisp. I also started with Coral way back when and liked what MCL had, so I understand what you are looking for; but at the same time I've come to believe that any truly native Lisp GUI is bound to be incomplete and will become obsolete very quickly. There is a more expanded version of this argument in the tutorial document contained in my contrib directory.

I have to guess at part of your argument until I see the contrib, but whatever it is I find it difficult to believe that it beats what I am looking for.  Before I say why, let me agree that every platform is a different burning platform, as we know by comparing windows and macs, and juggling the vagaries of carbon and cocoa and so on.  Much of this however, is just planed obsolescence which is designed to force us to buy new macs without radically changing what a user interface needs to do.

To my mind a user interface needs to provide some graphic-capable windows; routines for drawing, coloring and texturing lines and regions; a few dialog items for text and menus, dialog action functions and that's about it.  In short, we simple need a standard idiom for basic features like (open-graphics-window :size #@(200 400)) and (draw-line window #@(10 10) #@(190 390) *red-color* *grey-texture) and (place-menu window :items (list (list "Red" *red-color*) (list "Blue" *blue-color*)) :action #'(lambda (self) ...)) and related event handlers.   My GUI only uses that sort of thing.  (I am not sure whether array-dialog-item counts as more or not, I don't think it does as as far as I remember its all inside of lisp, or could be if not as all my extensions to it are.)  All my examples are built off those, and pretty much any application can be.  

To my way of thinking if Common-Lisp contained something that simple (something like quickdraw.lisp, menu-item and dialog-item.lisp) as part of the definition, most code would truly be portable.  Okay we also need something like the stuff in my Urwerk.lisp example for dealing with files, and something like opentransport.lisp to deal with streams.  But it is more or less these five things.

Of course many people will want more and they can have more.  Nothing should prevent them from getting the most out of Cocoa and friends,and the look and feel of their applications will look like the latest.   Mine meanwhile would look out-of-date but it would need next to no maintenance, it would just work with minor tweaks.  

Perhaps I am simply advocating (and begging) that those that go for more should define a layer like I advocate that opens up the basic functionality of PORTABLE COMMON LISP.  I would like to see an intermediate layer that is not all carbonised and cocoafied, except in the handful of files that defines  the lisp functions for (open-graphics-window #@(200 400)) and (draw-line window #@(10 10) #@(190 390) *red-color* *grey-texture) and (place-menu window :items (list (list "Red" *red-color*) (list "Blue" *blue-color*)) :action #'(lambda (self) ...)) and related event handlers.  As well as the rest of the handful, namely  Urwerk and Open-Westream with standard idioms for (file-date ) (directory ) (alias-file-p ) and (get-data-from-url ... ).

I think that if LISP is to remain relevant and rejuvenate itself, it must gather its many forces to define that intermediate level.  Perhaps an academic on the list should organise a LISP conference on it.  The language experts should gather pen and paper for a new standard that sets LISP ahead again.  Or perhaps, since I believe that the original Human Interface Guidelines that lead to it have not been surpassed by cocoa and osx, all we need to do is adopt quickdraw lisp and cocoa-ise it.  It seems to me that someone who knows cocoa and carbon should just change traps to something in cocoa  that works.

The danger otherwise is that we merely build planned obsolescence into our applications, rather than isolate it in a layer of our applications, which are otherwise conducted in LISP rather than java, carbon, or cocoa or xml...   all of which will have and deserve much shorter lifespans.

> 
> So instead I have been working towards making it as easy as possible to access Cocoa from within Lisp. I advocate using Apple's Interface Builder to do the fundamental design and Lisp code to provide data and interface functionality. If you buy into that approach you may find my tutorial helpful. If you don't, then some expansion of the EasyGui code (...ccl/examples/cocoa/easygui) might be more to your liking.
> 
> In the next month or so I plan to check in an update that provides a number of new things including a plug-in for Interface Builder that provides a "lisp controller" object that is very similar to the "NSArrayController" and "NSTreeController" objects that Objective-C Cocoa programmers have. But this controller knows how to manage lisp objects. It allows programmers to display arbitrary Lisp objects using NSTableViews or NSOutlineViews with little to no knowledge of Objective-C. In fact, the programmer will implement much of the needed functionality within Interface Builder by providing lisp initialization and accessor forms. This certainly isn't everything that you're looking for (it isn't everything that I'm looking for either), but it demonstrates how to start to make Cocoa accessible to Lisp developers. I have had this code working for a couple of months, but there are so many possible variations of what it can do that generating test cases to debug all the code paths and corresponding documentation for each example is consuming a lot of time.
> 
> After that I want to provide similar support for more advanced graphics apps, which I suspect from your examples is closer to what you ultimately want.
> 
> Regards,
> 
> Paul
>