Changes between Initial Version and Version 1 of CocoaIde/DesignNotes

Nov 22, 2008, 4:46:55 AM (12 years ago)



  • CocoaIde/DesignNotes

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