Issues For 3.2

[Stefan Xenos <sxenos@xxxxxxxxx>]

Here's my 3.2 wishlist. I'd like to humbly offer these for
consideration as 3.2 plan items.

Title: Major Issues for 3.2

Issues For 3.2

These are some of the issues I believe the UI team should consider for
3.2.

1. Eliminate Modal Dialogs

Modes reduce usability, and create concurrency issues by running
*syncExecs at unexpected times. All modal dialogs that can
be removed should be removed. Practically speaking, some improvements
would include:

• All methods that are permitted to open modal dialogs must be explicitly documented
• The preference dialog should be an editor (bug 87730)
  
• All error dialogs should be nonmodal ON_TOP shells rather than modal dialogs (check out Azureus for an example of how this is done).
• All the Team contributions (replace with version, compare with revision history, compare with version, etc.) should be done with the compare editor + revision history view, not modal dialogs.
• The launch configuration dialog should be a view (or a set of views + a perspective).
• All the "new file" wizards should be displayed inside an editor (rather than a dialog that opens a new editor after clicking "finish", the wizard itself becomes the editor for the file after clicking finish)
• The "properties" dialog should be displayed as part of the properties view.
• We should have support for part-modal messages. These would be controls that cover a single view or editor that could be used in place of a message dialog. Things like the "this file has changed on disk" message or the various CVS synchronization dialogs should use this support.
• Utilities like SafeRunnable should not open dialogs.
  

2. Institute a process for enforcing a consistent UI in the Eclipse SDK

We need to clean up our global resources such as keybindings,
preference pages, the global menu bar, and coolbars. This is hard to do
with our current development process because every committer is allowed
to
contribute to these shared resources, and every team uses different
criteria. The only way to fix this is if some team has the
responsibility to make these global resources
consistent, and has the power to do so. That team would have the
following responsibilities:

• Allocate globally shared resources (such as keybindings, actions on the main menubar, and the global namespace for views, preference pages, import wizards, and perspectives)
• Publish the UI guidelines and update them in response to community feedback
• Perform QC, and enforce the UI guidelines. The threat of removing nonconforming views, preference pages, etc. from the SDK should be enough to ensure that all teams conform.
  

Anyone can write a view, but it they should need to pass through some
sort of QC process (besides the stability and code quality tests done
by comitters)
before it can be included with the SDK.

3. Clean up preferences

• User preferences should be associated with the user, not the workspace. All workspaces should share the same preferences.
  
• Localize preferences. Remove preferences that apply to one specific part type from the global preference pages, and move them somewhere that is specific to that part. This would be easier if there were direct API support for part-specific preference pages (bug 98234).
• Provide a means to import / export preferences directly from the preferences dialog
• When importing / exporting preferences, preferences should be organized by preference page. The commonly-mentioned problem of preference pages reaching to global stores can be solved by encouraging preference pages to use the preference store provided by their container, or providing new API that permits preference pages to use a specific store. Preference pages in the SDK can be migrated, and any legacy preference pages won't be any worse-organized than they are now.
  

4. Editor tabs

When Eclipse is installed with the default settings, it should be
possible to see and read the tabs for every single open editor. To be
precise:
- The text in the tabs should never be truncated
- Every tab should be visible (users should never see a chevron or
scroller unless they have an excessive number of editors open - like,
say, 100)

Two possible solutions would be wrapped tabs, or a vertical list of
editors.

5. Standardize Common Code Patterns

There are patterns that are repeated in many places with incompatible
data structures. This creates code bloat, makes theAPIs harder to
learn, and prevents the creation of common tools (such as test
harnesses, utility classes, and code generation tools).

The following patterns should be generalized. In each case, we should
provide standard interfaces for the pattern, a means for clients to
implement it themselves, and API adapters that convert between every
existing old versions and the generalized version.

Pattern	Generalizes	Notes
XML tree	IMemento, IConfigurationElement, IPluginElement, DOM XML trees, IDialogSettings	Could be solved by writing an abstract implementation of IMemento that can be implemented by clients, and adapters to all the existing variations. Having a standard persistence object would make it easy to write an object that can be persisted anywhere.
Map of keys onto values with property change notifications	Preference defaults, Preference values, ITheme, IThemeManager, IPreferenceStore values, IPreferenceStore defaults, IPropertySource, any single node of an XML tree, ILaunchConfiguration	This is also needed for interchangeable persistence. I made a start at fixing this in the package org.eclipse.ui.internal.preferences, but many of the classes were deleted on 4/15/05 and will need to be restored from the repository. A general solution should permit the union and intersection of a set of maps to be used as a map, and should take into account that not all implementations support all operations. The same interface should not support separate "defaults" and "values" since this is the same as having two maps. "replace with defaults" can be accomplished by copying one to the other. Fon existing types that have the notion of defaults, separate adapters are needed for the defaults and the current values.
A reusable UI object that creates a set of SWT controls and communicates with an enclosing context	IWorkbenchPart and subclasses (IEditorPart, IViewPart), StackPresentation, IPage and subclasses (IContentOutlinePage, IPageBookViewPage, IPropertySheetPage, etc.), IDialogPage and subclasses (IPreferencePage, IWizardPage, IClasspathContainerPage, ISearchPage, etc), LayoutPart, IMemoryRendering, ILaunchConfigurationTab	This would permit all of these classes to be used interchangeably, instantiated by clients, and hosted anywhere. The component framework is intended to solve this problem, but considerable effort is still needed to finish the framework and to write adapters between all of these existing classes.

6. Import / Export wizard

The import wizard could use a facelift. See bug 90343 for suggestions
on how to refactor.

7. Launch Configurations

We could do a lot to make launch configs more user-friendly. The big
dialog filled with escoteric options, can be rather intimidating. When
a user goes to run their program, they are interested in three things:

1. Which program to launch
2. What input should be passed to the program
3. What environment should the program be run in
   

These should be the only three options a user sees when they click the
"run" button (even the term "launch configuration" may be unnecessary).
Users should be able to configure programs, environments, and inputs
separately, and mix-and-match them later. I'm not suggesting that we
should remove any flexibility from launch configs, but that we should
separate the options that define the program from those that specify
the program's input and the environment it will run in. See bug 89670.

The fact that it is a dialog at all is also a problem. Launching should
be done by nonmodal means (like a view) in order to allow the user to
browse classes, filenames, etc. while filling in the options. If the
user really wanted to see it as a dialog, they could always detach the
view.

8. Content Types

Content types are still a young technology and there is a lot of
opportunity for improvement in 3.2. See comment 17 in bug 37668, bug
57908, and bug 91965.

9. Problems View

The problems view should really be a "what do I need to do next" view.
The filters should be powerful enough for users to describe what they
find interesting, and it should be possible to view compiler-detected
things-to-do (problems) in the same list as user-identified
things-to-do (tasks). Segregating problems and tasks into two views
means that there is now two places to check, making it hard to tell
what needs to be done at a glance.

It should be possible to set up complex filters (with the UI equivalent
of boolean expressions and set operations), give them a name, and
switch between the named filters with a combo box or menu.

See bug 37974.

10. Improve community involvement on Eclipse.org

The website would be greatly improved by:

• Adding a voting booth where committers can ask the community their opinion about the most contraversial issues (bug 79225)
  
• Putting the Eclipse javadoc and help pages online
  
• Allow the community to comment on each help page and javadoc page (for example, see http://www.php.net/manual/en/ or http://crystalspace3d.org/docs/online/manual/)
• Ensure that all of the above is searchable on google, and can be read without entering a name and password