Version 2 (modified by gz, 12 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.

Design principles

Simple things should be easy. Hard things should be possible.

Things that people do all day every day should be quick and easy and obvious, even at the expense of making things that people do less often harder or more complicated.

Consistency is the hobgoblin of small minds. It's ok to recognize and hilight what's more commonly useful. (There is a design philosophy that says make everything neat and orthogonal; that is not our philosophy).

Defaults matter. In a way user interface design is about choosing the right set of defaults, the rest is a simple matter of implementation. The IDE should be useful out of the box without any customizations. Defaults should be biased to minimize the chances that a less sophisticated user would need to change them, but not to the point that more sophisticated uses would need extensive customization.

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

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.

Note that building up their own applications means partly adding their own kinds of windows and menus, but it often also means repurposing the IDE's windows and menus. E.g. using a (slightly modified) editor window as the application's interactive help window, or using a (slightly modified) listener window for the application's input, or using the Save menu item (or Copy or Paste or ...) on non-IDE windows without implementing their own menus.

Nib files

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.

There is no reason to avoid nib files, but we should select a set of conventions and use them consistently, regarding for example how to connect nib objects with lisp naming or with lisp event handling. Then we can implement some support for automating those conventions.

Text Editing

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
  • cut and paste should be integrated with the hemlock kill ring.
  • inserting deletes the selection
  • etc.

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...)

The EasyGUI design is provisional, untested by real use, and very much subject to change. It's just proof of concept, the concept being we can provide a simplified (and possibly cross-platform) model of programming a large common subset of GUI applications. If it turns out more useful in practice to not have windows be a subclass of views, we should change the EasyGUI design.

The IDE shouldn't use EasyGUI as much as we should try to make the implementation of the IDE provide some of the implementation of EasyGUI. I.e. when implementing stuff in the IDE, don't just think about how to get this one thing to work, think about making it reusable and packaged up for external use. Then it becomes part of EasyGUI.