Team Goals in no particular order:

1. Simplify the preferences UI
2. Establish the approach for adopting the R3.0 Core support for preferences
   1. define the compatibility story for both UI and Core existing API
   2. document a model that plug-ins should use when using preference scopes
   3. Import/Export - define strategy to be used for import and export re: scopes
3. Support better ways to make preferences available throughout the UI

Team:

• Monsignor Tod Creasey
• DJ Houghten
• Tom Eicher
• Martin Aeschlimann
• Michael Van Meekeren
• (Visual Design) Linda Watson

Planned Work for M4 (committed items):

1. Preference page sharing/navigation:
   1. editing multiple preference pages simultaneously /preference page dependancies
      1. Oct 19 - 26 Martin to investigate this as well as details related to how to keep information that is shared accross pages in sync
      2. Oct 26 - Nov 2
         1. See Tom and Martins documentation on overall preference navigation/usability/sharing
            1. linking style is supported but can be different per page
            2. will take up less space, need some guidelines for commonly used links like "advanced"
            3. need history controls to move back and forth
            4. what about jumping around in the lists when the selection changes
            5. how do you open a linked page on specific information
            6. searching, need to have a prototype
            7. working copy, need to have a prototype
         2. Example 1. Java build path affects other applications build path
         3. Example 2. pages show a preview but preview is affected by other pages
         4. Example 3. project options inherits from instance settings
         5. pages don't share information
            1. force apply when page left?
            2. working copy which is a copy of preferences that all pages are working on?
            3. pages should be organized better, combine pages via links or combining the
         6. Important to list the scenarios
      3. Nov 9 - 16
         1. prototype/patch implementation
         2. first pass for linking between pages behaviour is the same as R3.0
         3. ability to browse back and forward in response to this.
      4. Nov 18
         1. committed to JDT UI
         2. looking at forms code
         3. submitted a patch to bug 78878
            1. TC or MVM to look at the patch
      5. Nov 23
         1. TC - establish a story for the link widget
         2. make an example use case for this in the UI
         3. Non-internal version of preference page opening
            1. i.e. API to open on a page or switch to a page
            2. take an Object argument as well
            3. experimental for now
            4. wait to see what the solution is for filtering/highlighting pages to see what to do here
      6. Owner: MA (ZRH)
   2. preference sharing (teams contribute similar prefs to a common page)
      1. Owner: None
   3. Tree support in the Project Properties view bug 54128
2. Re-catagorize preferences to see if this solves the problems with finding the preferences
   1. Investigate links between pages
      1. searching and linking are usefull for managing lots of data but also good if someone tends to prefer it over reading the pages etc...
      2. Alternatives
         1. suggest that we provide examples/API to support links but not add to pref ext. pt. schema or bottom of a pref page by default
   2. Investigate combining pages that have common information
      1. Nov 9 - 16
         1. Seems like our three examples (label decorations, colors and fonts, editor properties) are very different
         2. suggest linking should solve this
         3. need back<->forward navigation support in the Preference Dialog so the user is not lost
      2. Owner: TC,MVM (OTT)
   3. Nov 23
      1. UI to review suggestions on page regrouping by TE and MA on pref pages
         1. DJ, TC and MVM to review the JDT team pref pages
      2. MA to fabricate some screen shots on hiding advanced pages

M5 finishing work:

After M4 there are a few items that we would like to revisit and work on independantly to 'complete' and polish what was done in M4, they are:

• Properties dialog (TC to do 82467)
  • put search in the dialog (consistent with preferences dialog)
• import/export (mvm to release ext. pt. - release for next Integration build)
  • add support for pluggable import/export wizards instead of import/export on the pref dialog
• M5 PreferenceService lookup order and support for listening on all scopes (DJ still working, need to talk to Jim)
  • need to re-visit API here
  • build something on top of the existing "too-powerful" core support to make a simpler programming model
• working copy (release for next Integration build)
  • use Colors and Fonts and Editors use of the same prefs to show colors as a case to prototype a working model API where preferences saved go to an intermediate pref. store so that pages can query this and get live information for preferences that have been changed in one page and not applied to the underlying store yet
  • * TC and DJ to released modified version of Martins work
    • for the next Integration build
• View settings (TC , log a bug and see what we can offer here bug 82566)
  • add a simple view (much like properties) so a view can open a dialog on its own preferences and not have them show up in the global prefs if not necessary
• View instance data persistance (find existing bugs and see if any exist if not log it)
  • currently two instances of the same view can not persist their setting which causes lots of strange behaviour when opening multiple Workbench windows for example and trying to set various options on views
• What happens with CDT when we apply grouping and they add themselves to the SDK (TC and MVM)
  need to also be able to change the labels (TC-MVM , TE)
  • reduce the need for override labels where possible
  • OR provide another label

Completed

1. Core API backwards compatibility (Goal #2)
   1. Document a plan with respect to the new API based on dyn. team input, document what that story is, publish to mailing lists for added visibility
   2. Oct 19 - 26 (THREE issues) See DJs doc on this
      1. ONE typed events
      2. TWO - some CORE API for setting prefs. (putValue) does not send prop. change events which ends up not updating the caches as the caches is changed as a result of an event, what should we do for cases where prefs are cached for example and no event is sent to update the value
         1. can not back out as this is API
         2. log bug reports checking uses of putValue as no event is sent
         3. update doc with hint that only non-API prefs should be used in this way if at all
      3. THREE
         1. plug-ins in RCP should be aware of the no data (no workspace) case.
         2. need to put some changes in workbench
   3. Oct 26 - Nov 2
      1. DJ to send note to mailing lists with potential problem areas
      2. porting guide
   4. Owner: DJ (OTT Core)
2. In-line opening of preference pages (Goal #3)
   1. Produce a patch to prototype version of direct preference page opening, Platform UI to evaluate agree on final version and implement
   2. Oct 19 - 26
      1. DP to cleanup a few issues around this work. Some API public yet, need to get Tom to try
   3. Owner: Tom (ZRH), Doug Pollock (OTT)
3. Pass through the preferences to see which ones should be view only preferences
   1. need some guidelines for views (MA - ZRH)
   2. Nov 18
      1. TE to check with MA to see if this really is what he was working on.
   3. Nov 26
      1. Search is an example here, how do we deal with view instance settings
      2. MA - to investigate
4. Functional high level category view in preference dialog (Goal #1)
1. Iterate over a Prototype new Preferences Dialog/Demo to dynamic team, to have something new in M3 with regards to functional top level preference categories
2. Simplified presentation for preferences and preference catagories
3. Easier navigation of the preference pages
4. Oct 19 - 26 - think of issues with high vs wide pref pages. Can we use the width better
   1. move icons along the top
   2. how do we deal with pref pages of the same name (e.g. Editors)
5. Oct 26 - Nov 2 Prototype #2 with list with large icons on left and expandable list on right
   1. need a design review
6. Nov 9
   1. sent samples snapshot to designers
   2. *** TC and MVM - how will catagorization work, how will it be flexible from the product level
   3. what about advanced being a dumping grounds for all other options?
   4. what about having an advanced button on each group so you can get all options?
   5. should not introduce another scope here (i.e. advanced).
   6. plan to finish for M4
7. Nov 18
   1. waiting on designers
8. Owner: TC (OTT Platform UI)
5. Initiate instrumentation work to help provide data for preference cleanup, goal is to have information by beginning of M4 (Goal #1)
1. Oct 19 - instrumentation plugins working on R3.0 and R3.0 M2
2. Oct 19 - 22 - decide on date when information can be obtained if possible
3. Oct 26 - Nov 2
   1. Instrumentation is under way
4. Nov 18 - Pilot instrumentation survey to be run this coming week
5. Dec 1, began survey
6. Owner: Michael (OTT Platform UI)
6. Catagories and Components
7. • how can we keep things simple for parenting of pages
   • * TC reorganized the schema, updated Platform plugin.xml
   • * Groups override parenting
8. what do we do with advanced topics? (DONE - use Other category)
   • hide advanced pages
   • advanced sections on individual pages
   • advanced category (i.e. group in the toolbar)
   • groups in the pref dialog map directly to capabilities aside from perhaps always having a "General" group

Full list of issues that were discussed (note: these are not all committed items):

* low priority
** medium priority
*** high priority

1. *** Make the UI simpler, current solution does not scale well, encourages too many categories
   1. UI model with leaning towards few logical/functional groupings at the top level
   2. The Import/Export support should only talk about being able to export things to the same extent that it can provide a human readable string for the items
   3. Currently categorized by plug-in
   4. Is there any way to enforce/restrict these categories on downstream products?
2. *** Clean up
   1. Remove legacy, unneeded, confusing preferences, advanced
   2. Use instrumentation tools to found out unused preferences vs frequently used
3. *** Backwards Compatibility
   1. Need to clearly define what we do/do not support in terms of backward compatibility for the Core API
   2. Write more tests?
   3. Scoped preference store tests
   4. Are we allowed to break APIs?
4. *** Sharing
   1. Other teams contribute "pages" to a shared page
   2. Decorators on three pages
   3. E.g. workbench contributes a category and other teams contribute (e.g. appearance)
      1. Not a hardcoded list
   4. Sharing an individual preference
      1. e.g. print margin is shared for all editors
         1. text font, overriding inherited prefs in some cases
5. ** Support to directly open a preference page (or open all prefs. but to a specific page)
   1. On a specific page
   2. Page might switch to a specific tab or group (i.e. don't talk in terms of the UI, but rather what is to be shown and the page figures it out)
   3. Option to show all pages, one page, or a part of the page
   4. Opening a single page or portion of the preferences
      1. ZRH has a prototype
6. ** Scalable
   1. Enable search for preferences
   2. Enable highlighting of
      1. pages in the tree
      2. controls (checkboxes...) on a page
      3. enable different navigation controls on the LHS of the preference dialog (see screenshots)
      4. ability to have a different view on the preferences
      5. should we keep the existing structure?
      6. How do we contribute this information? XML?
      7. Does the extension point mechanism scale that well?
      8. Don't want to aggressively activate plug-ins. (when searching)
7. * Locking/Access Control
   1. Requirements?
      1. Locking = remove from the UI? At the granularity of a page?
      2. Preferences that are not displayed in the UI
8. *Ability to apply preferences between page switch to help with inconsistent preferences
   1. Need a working copy of the preferences root
9. * API
   1. Do we need new API for associating human readable strings with preferences, or categories?
   2. Can we simplify the current API?
   3. Does this live in Core? UI? Could be at the Preference Page level
10. * Running background operations from a preference dialog (NEW ON OCT 19)
    1. E.g. ask for a build twice
11. Theme support on various levels
    1. (e.g. syntax highlighting themes, formatting themes, overall themes
12. Allow Export to export random preferences, not all preferences are stored in core
13. non-exportable preference/non sharable preferences
14. Need to deal with the three core layers that we have? Project, configuration...
15. Batched property change events
16. Bug 54392

Other Future Ideas:

• Auto-page generation based on preference types and predifined behaviour (e.g. boolean pref gets a check box and a label)
• Metadata for preferences? Store: user-readable name, groupings/dependencies, category, exportable flag, sharable flag
• When you export, it might not be exporting what you think you are since preference pages aren't explicitly linked to the preference store.
• Movement between tabs in preference pages -> marked as dirty until OK or APPLY is hit. Everyone implements their own ?working copy? strategy
  • Maybe work with a preference tree and then apply it to the real preferences? (note: the import/export mechanism at the Core level allows manipulation of a preferences tree and then apply it to the real tree)
• Displaying scopes in the UI
• Import/Export of project preferences -> When you import, you really want to apply these preferences to a specific group of projects in your workspace (underlying mechanism doesn't allow for this right now)

Team Goals:

• P1: Simplify the programming model for contributing menu and toolbar items to the workbench (and their corresponding appearance and behaviour).
• P1: Improved control over menu definition and item ordering. Scenario: Search and Run menus.
• P1: Allow the selected object in a view to override an action, e.g. Rename in Navigator on Java element yields refactoring rename
• P1: Maintain a strong separation between a command, its handler(s) and its placement(s) in the UI
• P2: Address difficulty in determining keybindings to show for context menu items.
• P2: Support dynamic entries in (top-level) menus, e.g. File > New submenu, window list, recent file list, Run > Run As..., QuickDiffToggleAction
• P2: Keybindings for object contributions
• P2: Ability to define a default command handler
• P2: Provide a localized command service for parts to use (generalize IKeyBindingService), and support nesting of parts.
• P2: Improve support for contributing items to nested parts/pages (e.g. console view scenario, bug 75737).
• P2: Resolve problems with object contributions in editors (new and experimental in 3.1). See bug 75273.
• P3: Allow the same item to be placed in the UI in multiple places, while minimizing duplication (e.g. of XML enablement expressions).
• P3: Look up and execute existing behaviour in the interface by identifier, e.g. to support welcome, cheat sheets, macros, scripting
• P3: Address JFace impedence mismatch: no notion of commands or keybindings at JFace layer
• P4: Make workbench actions available for others to place elsewhere in IDE.  Bug 71028.

Team:

• Nick Edgar
• Kai-Uwe Maetzel
• Douglas Pollock
• Michael Van Meekeren

Principles:

• Model/UI separation. Commands and command handlers/actions are specified independently of their placement in the UI.
• Universal extensibility. Every menu and toolbar can be extended - structurally and content wise. Explicit sealing of menus may be an option.
• Universal keybindings. From user's point of view, every menu item and tool item can have a user defined keybinding. From the system's perspective, every command can be triggered by a key binding.
• Separation of structure content. The structure of menus (i.e. which groups they contain) is defined independently from the content of the menus (i.e. the concrete items). Everything must be explicitly defined (e.g., there is no implicit definition of new groups in menus).
• Fine-grained control over visibility. Items can specify their visibility based on a context and its properties (think of core expressions).
• Container-managed enablement. Allow the container for an item to choose whether enablement of the item is computed eagerly or on-demand. E.g. menus items can be done on demand, but tool items will need to be done more eagerly. Items determine their enablement based on the associated command handler. This may also apply to visibility.

Documents:

• Scenarios for contributing menu items and toolbar items in the Workbench.
• Actions in the Navigator view (presentation, applicability, etc): HTML, Excel spreadsheet.
• Sketch of proposed changes to commands schema, with examples.
• Sketch of changes to Navigator view's extensions (does not correspond exactly with schema above).
• Collecton of old XML for some plug-ins' contributions
• Port of the contributions to the proposed schema

Code

The work in progress is available in CVS. You must check out "org.eclipse.core.commands", as well as the "dpollock_Doomsday" branch for "org.eclipse.jface", "org.eclipse.ui", "org.eclipse.ui.tests" and "org.eclipse.ui.workbench".

Planned Work for M5:

• Investigate pushing down refactoring participants mechanism to workbench and generalizing it to a general operation participants model.(db/ne/jml)

Planned Work for M4:

• Prototype sample API designed to unify/simplify and clarify (see bug 36968) the current set of contribution API's
  • API should fix the following among others:
    • difficulty determining keybindings to show for context menu items.
    • understand and plan for support of ordering of items (eg. action sets)
    • ability to declare a command and handler once, and support placement of the command separately.
      • Enablement is defined by the handler
    • see proposal coming soon
  • write regression tests
  • build sample/example test plug-ins
  • investigate lower level (e.g. JFace) related existing API to ensure consistancy
  • minimally support new API based on the existing code
    • time permitting enhance or re-write portions of the existing code for the following reasons:
      • does not support lazy updating in the UI
      • poor performance
      • complex submenu manager code
  • ISV doc showing migration steps and introducing the new API (ac, dp)

Completed Work for M3:

• Document scenarios for use cases for Actions (ne)

Team Goals in no particular order:

1. Provide a general framework for developing navigator views in the context of RCP or the Workbench
2. Framework should act as a test bed for new support for:
   1. retargetable actions
   2. operations framework
   3. working set enhancements for large workspaces
   non-resource based navigator support

Team:

• Billy Biggs
• Nick Edgar
• Dirk Baeumer
• Michael Van Meekeren

Planned Work for M3:

• Implement prototype generic navigator framework based on original "Generic Navigator" proposal
  • Owner BB (OTT)
• Investigate supporting working groups and filters (namely M3 additions in Package Explorer for managing large workspaces) in generic layer
  • Owner BB (OTT, DB to send pointers to code)
• Move re-targetable action work to Action Contributions dyn. team
  • Owner MVM (OTT)
• OTHER ITEMS
  • Operations (side note, not officially part of this work but recorded here)
    • NOTE JM (OTT) and DB (ZRH) to investigate a prototype for this then to come back in M4 with requirements for UI
    • Generalize Operations and push code down from LTK DB (ZRH)
  • Work on removing needed for LegacyResourceSupport class JM (OTT)

Ideas/Possible future work:

-