Changes between Version 1 and Version 2 of CocoaIde/DesignNotes

Nov 22, 2008, 2:22:18 PM (12 years ago)



  • CocoaIde/DesignNotes

    v1 v2  
    66but it's not clear that it makes any sense right now to try to limit our use of Cocoa to that subset supported
    77by such environments.
     9== Design principles ==
     11Simple things should be easy.  Hard things should be possible.
     13Things 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.
     15Consistency 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).
     17Defaults 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.
    920== Kinds of Users ==
    2233in order to reserve it for the user.
     35Note 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.
    2437== Nib files ==
    25 I'm pretty sure that it's not practical to create a Cocoa application that doesn't have at least a MainMenu.nib file.
     38I'm pretty sure that it's not practical to create a Cocoa application that doesn't have at least a !MainMenu.nib file.
    2639Depending on how we elect to do menus, we could have a minimal set of menus and build the rest up programmatically.
     41There 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.
    2843== Text Editing ==
    3348   * the Macintosh-style selection would denote the Hemlock region
    3449   * "normal" cut and paste needs to work
     50   * cut and paste should be integrated with the hemlock kill ring.
     51   * inserting deletes the selection
    3552   * etc.
    4158a subclass of views is odd...)
     60The 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.
     62The 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.