You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/Platform_UI_Command_Design.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -658,18 +658,18 @@ Original Requirements
658
658
659
659
1. Provide a single concept for contributing to the workbench. Right now, there are two distinct ontologies: actions and contribution items; and commands and handlers.
660
660
2. Support the addition and removal of plug-ins.
661
-
3. Separate model and behavior from visual presentation. Adhere more closely to the Model-View-Controller pattern. Model and user interface separation.
661
+
3. Separate model and behaviour from visual presentation. Adhere more closely to the Model-View-Controller pattern. Model and user interface separation.
662
662
4. Extensibility. Every group of items in the user interface (e.g., menu, tool bar, etc.) should be extensible – both in structure and content.
663
663
5. Universal keyboard shortcuts. A user should be able to add a keyboard shortcut to any item that appears in the user interface (e.g., menu item, tool item, menu, etc.).
664
664
6. Separation of structure and content. The structure of the menus (e.g., groups) should be defined independently from the items.
665
665
7. No implicit declarations of structure or content. Everything should be explicit.
666
666
8. Fine-grained control over visibility.
667
667
9. More intelligent updating of elements within the user interface. Support for lazy updating for elements that are not showing within the user interface. This lazy updating should be handled automatically – without the elements needing to understand whether they are showing.
668
668
10. Improved control over menu definition and item ordering. This will affect the “Search” and “Run” menus.
669
-
11. The selection should be capable of overriding the behavior of a user action. For example, if a Java element is selected in the Resource Navigator, a rename should be a refactoring rename.
669
+
11. The selection should be capable of overriding the behaviour of a user action. For example, if a Java element is selected in the Resource Navigator, a rename should be a refactoring rename.
670
670
12. Address the difficulty in determining the keyboard shortcuts to show for context menu items.
671
671
13. Support dynamic entries in top-level menus. For example, the recently opened files in the “File” menu should be possible using only public API.
672
-
14. There should be an easy way to define the default behavior in response to a user action (i.e., default handler for a command).
672
+
14. There should be an easy way to define the default behaviour in response to a user action (i.e., default handler for a command).
673
673
15. Provide localized control of the model, view and controller elements talked about in this proposal. This includes such concepts as automatic addition/removal as parts are become active/inactive, and automatic removal as parts are destroyed.
674
674
16. Allow the same user interface element to be placed in multiple locations. Reduce duplication in the syntax, and try to reduce memory usage.
675
675
17. Provide facilities for finding and triggering elements within the user interface. This is intended to provide better support for the welcome facilities, cheat sheets, macros and scripting.
0 commit comments