Team Goals in no particular order:
- Simplify the preferences UI
- Establish the approach for adopting the R3.0 Core support for preferences
- define the compatibility story for both UI and Core existing API
- document a model that plug-ins should use when using preference
scopes
- Import/Export - define strategy to be used for import and export
re: scopes
- 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):
-
Preference page sharing/navigation:
- editing multiple preference pages simultaneously /preference page
dependancies
- Oct 19 - 26 Martin to investigate this as well as details
related to how to keep information that is shared accross pages
in sync
- Oct 26 - Nov 2
- See
Tom and Martins documentation on overall preference navigation/usability/sharing
- linking style is supported but can be different per
page
- will take up less space, need some guidelines for
commonly used links like "advanced"
- need history controls to move back and forth
- what about jumping around in the lists when the selection
changes
- how do you open a linked page on specific information
- searching, need to have a prototype
- working copy, need to have a prototype
- Example 1. Java build path affects other applications
build path
- Example 2. pages show a preview but preview is affected
by other pages
- Example 3. project options inherits from instance settings
- pages don't share information
- force apply when page left?
- working copy which is a copy of preferences that all
pages are working on?
- pages should be organized better, combine pages via
links or combining the
- Important to list the scenarios
- Nov 9 - 16
- prototype/patch implementation
- first pass for linking between pages behaviour is the
same as R3.0
- ability to browse back and forward in response to this.
Nov 18
- committed to JDT UI
- looking at forms code
- submitted a patch to bug
78878
- TC or MVM to look at the patch
- Nov 23
- TC - establish a story for the link widget
- make an example use case for this in the UI
- Non-internal version of preference page opening
- i.e. API to open on a page or switch to a page
- take an Object argument as well
- experimental for now
- wait to see what the solution is for filtering/highlighting
pages to see what to do here
- Owner: MA (ZRH)
- preference sharing (teams contribute similar prefs to a common
page)
- Owner: None
- Tree support in the Project Properties view bug 54128
-
Re-catagorize preferences to see if this solves the problems with finding
the preferences
-
Investigate links between pages
- searching and linking are usefull for managing lots of data
but also good if someone tends to prefer it over reading the
pages etc...
- Alternatives
- 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
- Investigate combining pages that have common information
- Nov 9 - 16
- Seems like our three examples (label decorations, colors
and fonts, editor properties) are very different
- suggest linking should solve this
- need back<->forward navigation support in the Preference
Dialog so the user is not lost
- Owner: TC,MVM (OTT)
- Nov
23
- UI to review suggestions
on page regrouping by TE and MA on pref pages
- DJ, TC and MVM to review the JDT team pref pages
- 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
-
Core API backwards compatibility (Goal #2)
- 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
- Oct 19 - 26 (THREE issues)
See DJs doc on this
- ONE typed events
- 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
- can not back out as this is API
- log bug reports checking uses of putValue as no event
is sent
- update doc with hint that only non-API prefs should be
used in this way if at all
- THREE
- plug-ins in RCP should be aware of the no data (no workspace)
case.
- need to put some changes in workbench
- Oct 26 - Nov 2
- DJ to send note to mailing lists with potential problem areas
- porting guide
- Owner: DJ (OTT Core)
-
In-line opening of preference pages (Goal #3)
- Produce a patch to prototype version of direct preference page
opening, Platform UI to evaluate agree on final version and implement
- Oct 19 - 26
- DP to cleanup a few issues around this work. Some API public
yet, need to get Tom to try
- Owner: Tom (ZRH), Doug Pollock (OTT)
-
Pass through the preferences to see which ones should be view only preferences
- need some guidelines for views (MA - ZRH)
- Nov 18
- TE to check with MA to see if this really is what he was working
on.
- Nov 26
- Search is an example here, how do we deal with view instance
settings
- MA - to investigate
-
Functional high level category view in preference dialog (Goal
#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
- Simplified presentation for preferences and preference catagories
- Easier navigation of the preference pages
- Oct 19 - 26 - think of issues with high vs wide pref pages.
Can we use the width better
- move icons along the top
- how do we deal with pref pages of the same name (e.g. Editors)
- Oct 26 - Nov 2 Prototype #2 with list with
large icons on left and expandable list on right
- need a design review
- Nov 9
- sent samples snapshot to designers
- *** TC and MVM - how will catagorization work, how will
it be flexible from the product level
- what about advanced being a dumping grounds for all other
options?
- what about having an advanced button on each group so you
can get all options?
- should not introduce another scope here (i.e. advanced).
- plan to finish for M4
- Nov 18
- waiting on designers
- Owner: TC (OTT Platform UI)
-
Initiate instrumentation work to help provide data for preference cleanup,
goal is to have information by beginning of M4 (Goal #1)
- Oct 19 - instrumentation plugins working on R3.0 and R3.0
M2
- Oct 19 - 22 - decide on date when information can be obtained
if possible
- Oct 26 - Nov 2
- Instrumentation is under way
- Nov 18 - Pilot instrumentation survey to
be run this coming week
- Dec
1, began survey
- Owner: Michael (OTT Platform UI)
- Catagories
and Components
-
- how can we keep things simple for parenting of pages
- * TC reorganized the schema, updated Platform plugin.xml
- * Groups override parenting
-
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
- *** Make the UI simpler, current solution does not scale well, encourages
too many categories
- UI model with leaning towards few logical/functional groupings
at the top level
- 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
- Currently categorized by plug-in
- Is there any way to enforce/restrict these categories on downstream
products?
- *** Clean up
- Remove legacy, unneeded, confusing preferences, advanced
- Use instrumentation tools to found out unused preferences vs frequently
used
- *** Backwards Compatibility
- Need to clearly define what we do/do not support in terms of backward
compatibility for the Core API
- Write more tests?
- Scoped preference store tests
- Are we allowed to break APIs?
- *** Sharing
- Other teams contribute "pages" to a shared page
- Decorators on three pages
- E.g. workbench contributes a category and other teams contribute
(e.g. appearance)
- Not a hardcoded list
- Sharing an individual preference
- e.g. print margin is shared for all editors
- text font, overriding inherited prefs in some cases
- ** Support to directly open a preference page (or open all prefs.
but to a specific page)
- On a specific page
- 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)
- Option to show all pages, one page, or a part of the page
- Opening a single page or portion of the preferences
- ZRH has a prototype
- ** Scalable
- Enable search for preferences
- Enable highlighting of
- pages in the tree
- controls (checkboxes...) on a page
- enable different navigation controls on the LHS of the preference
dialog (see screenshots)
- ability to have a different view on the preferences
- should we keep the existing structure?
- How do we contribute this information? XML?
- Does the extension point mechanism scale that well?
- Don't want to aggressively activate plug-ins. (when searching)
- * Locking/Access Control
- Requirements?
- Locking = remove from the UI? At the granularity of a page?
- Preferences that are not displayed in the UI
- *Ability to apply preferences between page switch to help with inconsistent
preferences
- Need a working copy of the preferences root
- * API
- Do we need new API for associating human readable strings with
preferences, or categories?
- Can we simplify the current API?
- Does this live in Core? UI? Could be at the Preference Page level
- * Running background operations from a preference dialog
(NEW ON OCT 19)
- E.g. ask for a build twice
- Theme support on various levels
- (e.g. syntax highlighting themes, formatting themes, overall themes
- Allow Export to export random preferences, not all preferences are
stored in core
- non-exportable preference/non sharable preferences
- Need to deal with the three core layers that we have? Project, configuration...
- Batched property change events
- 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)
|
|
