Changes between Version 1 and Version 2 of CocoaIde/DesignNotes
- Timestamp:
- Nov 22, 2008, 2:22:18 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CocoaIde/DesignNotes
v1 v2 6 6 but it's not clear that it makes any sense right now to try to limit our use of Cocoa to that subset supported 7 7 by such environments. 8 9 == Design principles == 10 11 Simple things should be easy. Hard things should be possible. 12 13 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. 14 15 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). 16 17 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. 18 8 19 9 20 == Kinds of Users == … … 22 33 in order to reserve it for the user. 23 34 35 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. 36 24 37 == 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.38 I'm pretty sure that it's not practical to create a Cocoa application that doesn't have at least a !MainMenu.nib file. 26 39 Depending on how we elect to do menus, we could have a minimal set of menus and build the rest up programmatically. 40 41 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. 27 42 28 43 == Text Editing == … … 33 48 * the Macintosh-style selection would denote the Hemlock region 34 49 * "normal" cut and paste needs to work 50 * cut and paste should be integrated with the hemlock kill ring. 51 * inserting deletes the selection 35 52 * etc. 36 53 … … 41 58 a subclass of views is odd...) 42 59 60 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. 43 61 62 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. 44 63 45 46
