[Openmcl-devel] Lisp User Interface LUI

Wed Jan 14 18:52:18 PST 2009

On Wed, 14 Jan 2009, Alexander Repenning wrote:

> I can't say that I am huge fan of C++
>
> Based on all the input so far I would conclude on the Mac side to continue 
> with LUI by building a shallow Cocoa wrapper on Macs (e.g., using generic 
> names: details in diagram below) and building the same class hierarchy  on 
> Win and implementing it on top of the win32 api.  I am not sure that much is 
> to be gained by adding a layer between win api and Lisp. C++ as intermediate 
> layer could be ugly and other tools that based on scripting languages (e.g, 
> Ruby) could be slow.
>
> Once we have a good FFI for CCL win would it really be that hard to access 
> the win api directly?

The FFI for CCL on win32 is exactly the same as the FFI for CCL on
other platforms.  (At one point, it seemed to be true that DEFCALLBACK
on Windows needed to have some way of saying that the callee - not the
caller - popped the callee's args off of the stack; that's been around
for a few months and the just-barely-interesting "mswin.lisp" example
uses it.  So, it's "the same FFI, but I think that this
:DISCARD-STACK-ARGS thing only really works on Windows.")

We don't have anything -but- the FFI to use to access Win32, but the
COND in the SIMPLE-WINDPROC callback in ccl:examples;mswin.lisp could
certainly be extended to have more than one non-default clause (the
one that handles #$WM_DESTROY) messages.)  I -think- that there are a
few hundred standard windows messages (small integer constants) that
are in some sense widely used (some of these may only be pertinent to
certain types of controls).  A "real" windows procedure would almost
certainly need to handle WM_PAINT messages (requests to draw the
content area), handle various flavors of resize, handle keyboard and
mouse events ... the COND or CASE would probably have at least a few
dozen clauses.  (It's hard to know how accurate this estimate is; I
don't think that too many people write Win32 code anymore, at least at
this level.)

Whether that estimate (a few dozen "interesting" windows messages/
event types would need to be handled by a typical wndproc) is high or
low, it's probably fair to say that writing event handling code as a
series of CASE statements doesn't scale particularly well or lend
itself to reuse.  The same was true in classic MacOS, where
-supposedly- every program had to contain code that micromanaged
details of event managment ("the mousedown was in the window's close
box ?  Hmm.  I wonder what we should do in response ? Probably the
same thing that we did the last time ...")

You can certainly put some thought and effort into trying to dress
up Win32 (according to how important it is, you can put various
levels of thought and effort into it.)  It might be the case that
you (Alex) would find that the needs of your project could be met
without trying to solve the more general problem of making Win32
development sane/easily extensible/easily reusable.

>
> not sure this diagram makes sense out of context:
>
> instead of
>
>
> On Jan 14, 2009, at 4:40 PM, Gary Byers wrote:
>
>> If it's possible (license-wise) to bundle QT wih CCL - and desirable
>> to do so - the next step (or at least a step that'd have to be taken
>> at some point) might be to try to figure out things like "what is this
>> C++ thing ?  how does one arrange to correctly call C++ methods and
>> have lisp code called from C++ code ? can one define new C++
>> (sub)classes at runtime and define methods on them ?"
>> 
>> There may be other questions that're more relevant.  Any time that
>> I've tried to understand C++ at this level, my eyes have glazed
>> over and I've gotten a bad headache.
>> 
>> Since many language implementations (those that aren't C++) often
>> (a) face similar issues and (b) know how to interpoperate with C
>> if not C++, many C++ libraries offer a C API to at least some
>> (possibly large, possibly not) subset of their functionality.
>> Sometimes (I think that it's fair to say "often", but that
>> view may be skewed by a small sample size) the C bindings lag
>> a version or two behind the wrapped C++ library's functionality,
>> and in some cases the project that maintains the C bindings
>> stagnate (the maintainers complain of blurred vision and
>> painful headaches ...)
>> 
>> I've seen (on this mailing list, maybe 5 years ago) some
>> lisp<->c++ code that someone was working on; all that I
>> remember of it was that it was suprisingly simple, clean,
>> and elegant (as if the author didn't realize that what
>> they were doing was hard ...).  I think that we tried to
>> contact them a few years ago but their email address had
>> changed.
>> 
>> I don't know enough about QT to have an opinion of whether
>> it'd be a good choice as a cross-platform GUI toolkit for CCL.
>> It'd be good to at least be able to "here's some FFI stuff
>> and maybe some stuff on top of that, so anyone who wants
>> to try using QT from CCL can at least do so", and the same
>> is true for wxWidgets and other GUI and non-GUI C++ libraries
>> and toolkits.
>> 
>> Unfortunately, we aren't there.  It might indeed be the case
>> that getting there (to the point of useful C++ interoperability)
>> isn't incredibly difficult, but the symptoms of C++ exposure
>> (dread, revulsion, nausea) are certainly real even if they
>> may not be well-founded.
>> 
>> 
>> 
>> On Wed, 14 Jan 2009, Raffael Cavallaro wrote:
>> 
>>> 
>>> On Jan 7, 2009, at 8:43 PM, Alexander Repenning wrote:
>>> 
>>>> QT is probably one of the most successful cross platform tools.
>>>> 
>>>> I am not sure if CCL could just bundle QT given its license. On the
>>>> Mac it may be hard to mix QT with native Cocoa
>>> 
>>> 
>>> It's recently been announced that the next version of QT (4.5) which
>>> is due out in March will be released under the LGPL. This is good news
>>> for those wanting to use it with CCL because they will both use
>>> essentially the same license:
>>> 
>>> <http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt>
>>> 
>>> regards,
>>> 
>>> Ralph
>>> 
>>> 
>>> 
>>> 
>>> Raffael Cavallaro, Ph.D.
>>> raffaelcavallaro at mac.com
>>> 
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>> 
>>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>> 
>
> Prof. Alexander Repenning
>
> University of Colorado
> Computer Science Department
> Boulder, CO 80309-430
>
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>
>