|Version 1 (modified by rme, 6 years ago) (diff)|
It's for the Macintosh
It probably should go without saying, but the Cocoa IDE is targeted at the Macintosh.
There are some environments out there that aim to implement at least parts of the Cocoa API on other platforms ( GNUstep, Cocotron), but it's not clear that it makes any sense right now to try to limit our use of Cocoa to that subset supported by such environments.
Kinds of Users
Some users will see the IDE as something to use instead of Emacs/SLIME. Of course, these users will probably wish to be able to extend the IDE in the same way that users extend Emacs and SLIME.
I've seen at least one person on IRC express interest in using the IDE as a swank client, so we might keep that sort of thing in mind. The thought being, I guess, that one could connect a remote SBCL or something from the (presumably) nice Cocoa IDE. (Recall that there's code available that turns MCL into a swank client; see http://clozure.com/pipermail/info-mcl/2008-September/000441.html)
Others will see it as a starting place for building their own applications: in essence, they will wish to build up the IDE until it turns into their application. Awareness of this might cause us to make certain design choices. For instance, we may wish to avoid using the Cocoa document architecture in order to reserve it for the user.
I'm pretty sure that it's not practical to create a Cocoa application that doesn't have at least a MainMenu?.nib file. Depending on how we elect to do menus, we could have a minimal set of menus and build the rest up programmatically.
We want to use normal Macintosh-style text-editing conventions. Even an emacs like Aquamacs, which tries to mimic Macintosh-style behavior when possible, doesn't have a native feel. Fred did well at feeling native back in the day.
- scrolling with the scroll bar shouldn't move the insertion point
- the Macintosh-style selection would denote the Hemlock region
- "normal" cut and paste needs to work
Making Cocoa more Lispy
I think it's desirable to add some sort of lispy interface to the Objective-C Cocoa API. It doesn't need to cover every corner of the framework, but some sort of CLOS-based interface to basic windows/views/controls/menus would be pretty useful. Perhaps Easy GUI is the thing to use, perhaps not. (I still think that having windows be a subclass of views is odd...)