Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Equinox p2 UI Plan
Revision as of 16:08, 10 June 2008 by Susan franklin.us.ibm.com (Talk | contribs)
This page describes the work planned for the next release (3.5) of the p2 UI. This includes improvements for the p2 UI in the Eclipse SDK, as well as issues that have to be addressed for alternate UIs (such as RCP app requirements).
The milestone plans for 3.4 have moved to Equinox p2 UI Eclipse 3.4 Plan
3.4.1 Issue List
- Improved progress reporting and honoring cancellation requests
- Investigate less eager loading of repos by the UI Bug 236485
3.5 Issue List
UI/Usability
- Usability review of general strategy (modality, overall organization, etc.)
- Initial walkthrough by Eclipse UIWG scheduled for 6/25/2008
- Improved implementation of installed view
- Ability to view different levels of detail Bug 224472
- Separation of product base vs. "add-ons" Bug 215398
- better affordances in available view to show already installed, available updates, etc. Bug 216032
- this detail should be shown also in install/update dialog
- handling and presentation of repos
- Need to do a better job of deciding which repos to look up against Bug 234213
- better organization for known/discovered/disabled repos and discovery mechanisms Bug 218534
- streamlined license UI Bug 217944
- user repo naming (regression of UM function) Bug 194224
- improved revert view with annotations for snapshots Bug 216031
Performance/Stability
- revisit checkbox/filter/deferred fetch strategy Bug 233269
- resolution in the background Bug 236495
API
- Level of detail provided by API (listed from most general to most granular)
- Separation of contributions from the rest of the code
- Pluggable interfaces to preconfigured UI (query providers, policies, etc.)
- Ability to place basic UI in different containers (dialog vs. pref page)
- Ability to reassemble groups (available, installed, history) into new UI
- Expose building blocks for RCP apps
- Individual wizards, dialogs, actions
- Content and label providers
- Moving UI code to the core
- should UI be the one coordinating provisioning operations vs. having scheduling rules
- event batching when multiple changes are made
- improved error reporting and explanation of problems before the UI (PlanStatusHelper should be in
the planner itself)