[Openmcl-devel] Lisp User Interface LUI
gb at clozure.com
Wed Jan 14 22:44:08 PST 2009
I've tried a few times to actually build Cocotron (and its cross-development
tools.) I haven't had much success, but as far as I can tell that's because
I don't have one or more of (a) the right version of XCode installed (b)
sufficient knowledge of or interest in XCode to resolve what are likely
simple problems and (c) the patience to do so.
At some point, the way to make progress would likely be:
- take the version of gcc (and related tools) that Cocotron uses as a
cross compiler (this is roughly gcc 4.3 and includes support for Apple's
ObjC 2.0 extensions) and build that natively on Windows.
- take the cocotron sources (for AppKit/Foundation/other stuff) and
compile them on Windows, using the compiler/toolchain produced above.
Install the header files somewhere (on a Windows system), and run an
interface translator (which understands those Apple ObjC 2.0 extensions)
over them, producing a set of .cdb files.
- try to understand the differences between the ObjC runtime that Cocotron
uses and Apple's. (Cocotron's may be similar to the GNU ObjC runtime,
for which there was once almost-complete support in CCL's ObjC bridge.
Or it may be different, or a hybrid of the Apple and GNU runtimes.) Make
whatever changes are necessary to the bridge in order to conditionally
support the runtime that Cocotron uses. (It's possible that this might
involve changes to other parts of the lisp, depending on how ObjC exception
handling is done in Cocotron.)
There might still be some issues: Cocotron's intended to be used as a
cross-development environment, so you'd have to build nib files on a
Mac. If all of the above is done right, then you'd be at roughly the
same point that the people who wrote the blog entry that Alex
mentioned describe: a lot of Cocoa stuff works in Cocotron, some stuff
doesn't, the project's generally moving forward and stuff gets fixed.
Some of these steps could be avoided by using GNUstep for Windows
(instead of Cocotron.) There might be ways to persuade GNUstep to use
a more native look and feel, but out-of-the box, a GNUstep example
program running on XP looks like:
On Wed, 14 Jan 2009, Alexander Repenning wrote:
> I had looked, only quickly, at Cocotron but did not spend enough time
> exploring it after not finding any commercial app actually using it. However,
> looking at it again - thanks to your post- I found this interesting story:
> This includes some screen dumps and must say it does not look bad (for Vista
> Perhaps it is ready to go. If one could bundle this with CCL and use the same
> objective-c bridge one could save a lot of work. Not surprisingly, there is
> some functionality missing but I guess that would still be better than
> dealing with super low level win api kinds of issues.
> Gary, any guestimates on how hard this kind of integration would be? In
> theory even the Cocoa based CCL hemlock implementation may actually work on
> Cocotron allowing CCL win to have a "real" IDE.
> sounds exciting, Alex
> On Jan 14, 2009, at 6:48 PM, Brian Mastenbrook wrote:
>> Alex and others on the list,
>> Have you seen Cocotron (@ http://www.cocotron.org/ )? It is an open source
>> project to provide a MIT-licensed implementation of the Cocoa APIs on
>> Windows (and they are considering supporting other platforms in the
>> future). Perhaps it would be less effort in the long run to rely on a
>> project like this than implementing a new cross-platform API.
>> Qt theoretically does this too but like others I am not a huge fan of C++.
>> If your solution is all C or C++ then Qt is probably the easiest way to get
>> a cross-platform GUI. But it can't be bound to very easily.
>> Another option might be to use Cocoa on OS X and GTK+ on Linux and Windows.
>> GTK+ applications look very good on Windows, and the API is much cleaner
>> than the native Win32 APIs.
> Prof. Alexander Repenning
> University of Colorado
> Computer Science Department
> Boulder, CO 80309-430
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
More information about the Openmcl-devel