[Openmcl-devel] all I want is a (cocoa) window...

[Paul Krueger]

My new development tools are still coming "real soon now". They are now working in pretty much every way that I would like them to. As I document however, I find little things that need to be cleaned up and I'm something of a perfectionist, so I don't want to release something that people will find to be too buggy. And I keep adding new constraint checks to keep people from shooting themselves in foot.

As for niblessness, if all you want is a window in which you can directly draw using graphics commands, that is pretty darned easy to do and IIRC there are examples already present in some of the CCL code. I have at least one example of that in my tools where I pop up a very simple proxy window if a user has yet to define a window to represent their document (actually just a simple text line in that window, but adding graphics would be easy). But once you start to add more sophisticated control objects like sliders, check boxes, color wells, image wells, and text fields, tables, etc. and want to configure and arrange them in all the myriad ways that Cocoa allows, then you really want to use IB to create NIBs because it makes that process SO much easier. The main example used in documenting my tools is, in fact, a graphics window, but it has a few associated controls as well. It supports the normal save, open, print, and undo mechanisms of typical Cocoa programs with very little additional effort on the part of the Lisp developer. This example application would provide a pretty good starting template for anyone who wanted to create their own application that displayed a graphic window.

I think what has made using IB less useful for Lisp programmers is the process of exchanging data back and forth between Cocoa objects and Lisp, so that is one of the major areas that my new code addresses. I added the ability to bind values in interface objects to Lisp slots using normal Objective-C binding mechanisms (via a Lisp controller object I've added as an IB plugin). Data values are automatically converted back and forth between them. The only thing you need to do in Lisp to make that possible is to add a slot declaration that specifies the string that will be used as the binding target. The implementation of the Lisp tools itself uses this mechanism extensively to interact with its window interface objects. And if you need to immediately do something when a value has been changed by a remote object there is a mechanism for defining a function to be called when that happens. Bindings can also target arbitrary lisp methods and will return whatever they return. The syntax for that is a little kludgy because there isn't an easy way to specify package qualifiers using allowable binding strings in Objective-C (no colons permitted), but I've defined something that works.

I also have a collection of functions that will help you do manual data conversion whenever you need to do that. There are high level functions that convert back and forth between arbitrary Lisp and Objective-C data types using reasonable defaults or lower-level functions that you call if you want a more specific sort of conversion. There is code that will take any Lisp instance and create an appropriate Objective-C structure that can be saved to disk and restored using normal Cocoa methods and much more.

I think if you decide to create your own dynamic interface language that is heavy on graphics and light on controls and data entry, then Niblessness becomes more reasonable. If you're doing an interactive game, for example, I can't imagine that you'd use many nibs (maybe just for configuring the game). As far as I can tell there is nothing anywhere in Cocoa that mandates that you have NIBs. After all, when NIBs are loaded at runtime, all the objects represented there are instantiated using generally available Cocoa functions. Nothing there that you couldn't do yourself; but don't mistake that for saying that it is simple. These are complex objects that often need to be configured in very precise ways if you want them to work correctly. And of course you also have the problem of maintaining and enhancing your language as the underlying Cocoa functions evolve, but presumably that's the commitment you made when you decided to create your language in the first place.

Paul

On Jan 12, 2011, at 3:07 AM, peter wrote:

> At 5:39 PM -0500 11/1/11, R. Matthew Emerson wrote:
>> Sometimes, all you want is a plain window that you can pop up and draw stuff into.
> 
> Many thanks for bringing this up. I've been struggling to morph a constraint frame systems approach into IB/NIB form. I'm sure the standard speech is that the latter is the only way to go.  But it is such a relief to hear that nibless graphics is not sin-binned by Apple.
> 
> On my wish list, niblessness added to Paul Krueger's contrib (looking forward to the next release inc documentation).
> 
> Care to volunteer any restrictions/limitations to a nibless approach?
> With Jobs saying "all of the new apps of the past few years are nibless" in 2008, perhaps its not too far off track.
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel