Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "E4/Eclipse Application Model"

< E4
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
a.k.a. "the twenty things"
+
#REDIRECT [[E4/Eclipse_Application_Services]]
 
+
This is a first list of "recommended APIs" - things that we expect most Eclipse plug-ins would make use of (if applicable). The goal is to reduce bloat by focusing on a smaller subset of core recommended Services and APIs. If these Services and APIs are also structured in a similar and consistent manner, it will also simplify understanding, foster [[Architecture Council/Minutes May 15 2008#Becoming More Asynchronous|Becoming More Asynchronous]], and make it possible to solve the [[Architecture Council/Minutes May 15 2008#Too Many Listeners|Too Many Listeners]] problem.
+
 
+
Note that "the Workbench", "PlatformUI" or "Platform" are not on this list. Think of which services you would want to use from within your contributed view or editor.
+
 
+
''Kevin McGuire - Some of these support a component model, and some provide an application framework of common elements. It'd be worthwhile to identify this split since the former are essential for a web based Eclipse component model. For example, Selection service is needed so one can write independent views/editors and have them work together. Without it, there's no component interaction. Similarly, IMenuService and commands allow fine grain component interaction, so one plugin can say add a menu to a view it doesn't know about. UI State persistence though can be supported in a number of ways.  Help is purely an application framework item.''
+
 
+
''Kevin McGuire - We should have Commands as a top level item although we have an entire subject page on [[E4/Commands | commands]]. Plus here need to tie commands in with menu service and handlers (not sure right organization)''
+
 
+
* '''From [[Architecture Council/Minutes May 15 2008#Eclipse Application Model]]''':
+
** Besides the List of Services we're compiling now by hand, we'll need a '''strong way of describing the Services''' for E4 -- as a medium for newcomers to understand Eclipse -- perhaps Tooling to make Service Descriptions machine readable / usable. In the beginning, '''Every Service should have a Wiki page describing it''' and the Architecture behind it (probably linked from this Summary Page.
+
** Especially when Services go on the Server (Sessions, Macros Recording), need a consistent Story for exposing a Service, its state and commands, need to be [[Architecture Council/Minutes May 15 2008#Getting rid of Singletons|Getting rid of Singletons]]
+
** <s>Mik to write Position Papers on new '''Focus Service''' and '''Notification Service'''</s>
+
** Application Model is related to almost all other architectural topics ([[Architecture Council/Minutes May 15 2008#Too Many Listeners|Too Many Listeners]], [[Architecture Council/Minutes May 15 2008#Becoming More Asynchronous|Becoming More Asynchronous]], [[Architecture Council/Minutes May 15 2008#Dependency Injection|Dependency Injection]], Sessions, Macro Recording)
+
 
+
* One goal of this session could be to '''organize services''' into some grouping with similar Properties.
+
** For instance, IExtensionRegistry, IAdapterManager, IProgressService and IPreferencesService seem to be similar in that they are all very low-level, non-UI services.
+
** Kevin also mentioned the "component model" vs. "application framework" kind of separation.
+
** Another separation could be Services that maintain some kind of internal state / require session information vs. others that do not.
+
** Yet another separation could go along the lines of [[E4/ClientServer|Client / Server]] split: What could go on the client and what could go on the Server.
+
 
+
=== Selection ===
+
ISelectionService - Listening to the current selection
+
 
+
=== Adapting objects ===
+
IAdapterManager - adapt an object (typically, the current selection) to a type that is relevant to the current plug-in
+
 
+
=== Scheduling background work ===
+
IProgressService - Schedule work in a way that is visible to the user
+
Job, IJobManager - schedule and manage background jobs
+
 
+
=== Help ===
+
IWorkbenchHelpSystem
+
 
+
=== Undo/Redo ===
+
IWorkbenchOperationSupport
+
 
+
=== Preferences ===
+
IPreferencesService - retrieve and modify preferences
+
 
+
=== Handlers ===
+
IHandlerService - register a handler for a global command like Copy/Paste
+
 
+
''Bjorn asks:'' where is the list of the global commands? Do we have a namespace of commands? Can any plug-in contribute to the set of commands? How do we know what the semantics of a given command are? -- See also [[E4/Commands]]
+
 
+
=== UI Contributions ===
+
IMenuService - programmatic contribution to menus and toolbars
+
 
+
=== Open web pages ===
+
IWorkbenchBrowserSupport
+
 
+
=== Decorations ===
+
IDecoratorManager
+
 
+
=== Common UI Elements ===
+
Wizard framework, Dialogs
+
''--- Added - KevinM''
+
 
+
=== Dynamic enablement ===
+
IExtensionTracker - ability to react to components coming and going at runtime
+
 
+
=== UI state persistence ===
+
IDialogSettings, IMemento - Persistence of UI state: layouts, dialog sizes, viewer selection and expansion state
+
 
+
=== Extension registry ===
+
IExtensionRegistry - registering and accessing extensions and extension points
+
 
+
=== Notification Service ===
+
 
+
''Initially contributed by Mik Kersten, for questions use: {{bug|233142}}''
+
 
+
==== Problem ====
+
 
+
Some applications need to inform the user of events in the workbench that may require attention, whether or not the workbench is visible.  An increasingly standard way of doing this is to use a desktop notification popup, often appearing for a fixed amount of time in the bottom-right hand of the window.  As an example, Mylyn has a custom notification mechanism to inform the user when a Bugzilla report has a new comment.  The popup shell is now part of the reusable <code>org.eclipse.mylyn.commons.ui</code> plug-in, and could be moved into Platform (see {{bug|177974}}).
+
 
+
In Eclipse UI land, the need for a notification mechanism boils down to some view part <code>IWorkbenchPart</code> requesting attention from the user.  UI Experience on Mylyn indicates that it is better to have interactivity come from the pat itself, rather than making the user interact with the tiny and transient popup.  In other words, the popup becomes an overview link to one or more notification items whose details are present in the part.  The part can be a view, as is the case with Mylyn's ''Task List'', or with a view that shows an event log and desires to inform the user of new events, or with a view that wants to inform the user of progress completion as could the ''Synchronize'' view.  Or it could be an editor, as is the case with Mylyn's task editor which can show incoming notifications.
+
 
+
==== Proposal ====
+
 
+
We already have examples of progress support for views such as ''Synchronize'', whose title will go italics for the duration of a synch.  We also have some support for this in editors with form's busy spinners and Mylyn's busy spinners in the editor tab (see {{bug|175592}}).  The proposed ''Notification Service'' would build on this idea to make it possible for a view to queue and display notifications on progress and incoming events.
+
 
+
=== Focus Service ===
+
 
+
''Initially contributed by Mik Kersten, for questions use: {{bug|233142}}''
+
 
+
==== Problem ====
+
 
+
Mylyn provides a task-focused interface for Eclipse, which affects the way that view filtering, expansion and decoration work.  This boils down to viewers and editors showing only the structural information relevant to a task (e.g. Bugzilla report) instead of all of the underlying information available in the corresponding content provider(s).
+
 
+
The following resources provide an overview of the facilities and their impact on viewers and a summary is provided below.
+
* A user-centric overview of the UI is in the tutorial article: http://www.ibm.com/developerworks/java/library/j-mylyn2/
+
* Detailed description of the facilities is in the PhD theis: http://kerstens.org/mik/publications/2007-01-mik-thesis.pdf (pages 39-40)
+
 
+
The following task-focused interface mechanisms affect views and viewers:
+
* '''Filtering''': uninteresting elements are filtered from the view by an <code>InterestFilter</code> which is applied when the view is focused.  Applying the interest filter causes all other viewer filters to be removed, since the <code>InterestFilter</code> hides all elements by default.  Filtering requires the view to be lazily refreshed based on task context model changes in addition to content changes.
+
* '''Expansion and linking''': focused viewers always have their nodes expanded by default and are always linked to the editor, since they are much less likely to show a scrollbar.
+
* '''Decoration''': all focused viewers use a lightweight platform decorator to indicate interest level (e.g. gray is uninteresting and bold font is a very interesting element).
+
* '''Ranking''': sort order can be changed to bring the most interesting elements to the top (e.g. in a table viewer or a content assist list)
+
 
+
The following task-focused mechanisms work on editors:
+
* '''Folding''': uninteresting elements are automatically folded away in textual editors.
+
* '''Filtering''': uninteresting elements are automatically filtered from graphical editors.
+
 
+
The following task-focused interface mechanisms affect the workbench:
+
* '''View management''': views are automatically focused (i.e. facilities listed above are applied) when a task is activated.
+
* '''Editor management''': open editors are automatically matched to the task context (e.g. all closed when a task is deactivated, all restored when reactivated, if an element decays in interest the editor auto closes). 
+
* '''Perspective management''': perspectives are automatically associated with tasks and activated when tasks are switched.
+
 
+
==== Proposal ====
+
 
+
Currently Mylyn makes heavy use of Platform internals to support the task-focused interface.  In places it leverages or overrides workbench behavior, as with it's management of mementos for restoring editors.  In other places it needs to gain reflective access to hidden parts of the workbench, as with the need to add decorators and filters to the Markers views.  The proposed ''Focus Service'' would remove the need for internals and make it possible to apply the focus mechanisms to a viewer or other workbench facility if that viewer met the service's simple contract (e.g. the view part contains one or more structured viewers), and provide the focus service access to the required UI mechanisms without overly exposing internals (e.g. injecting the task context model refresh policy into the viewer alongside its content model refresh policy).
+
 
+
=== Other Services not yet Decided on ===
+
* From [[Architecture Council/Minutes May 15 2008#Eclipse Application Model]]:
+
** Capabilities
+
** Content Types, Associations
+
** Markers
+
** Workspace, Resources (related to Team Support)
+
** Launching Framework
+
** Core Variables / Launch String Substitution
+
** EFS (core.filesystem)
+
** OSGi Stuff (NLS, ServiceTracker, Bundle States / Activator / Classloader; Log; State Location)
+
 
+
* The standard bundle layout also seems part of the Application Model ("how Eclipse is built"): MANIFEST.MF and Eclipse-specific extensions, Eclipse.inf, Features etc (related to Provisioning / Update / Plugins, Products, Features)
+
[[Category:e4]]
+
 
+
 
+
=== Notes from e4 break out session ===
+
* Missing: Roles, logging, Usage monitoring
+
**Does Views and Editors belong to that list?
+
 
+
*What is the importance of each item? Order. Essential / Incidential
+
 
+
Trying to find categories:
+
<pre>Operations (commands) --|
+
                        | - command bus
+
Listeners            --|
+
 
+
Data (model)</pre>
+
 
+
Trying to order it:
+
 
+
'''Data model (a rest service)'''
+
- Adapting object
+
- Selection (currentSelection)
+
- UI Contributions
+
- Decorations
+
- Common UI Elements
+
- Persist State
+
- Extension Registry
+
- roles
+
 
+
'''Command Bus (a javascript function)'''
+
- Selection (change)
+
- Undo/Redo
+
- Handlers
+
- Dynamic enablement
+
- Notification Service
+
- Focus service
+
- logging
+
- usage monitoring
+
 
+
'''Other things'''
+
- Help
+
- scheduling background work
+
+
 
+
What is the right set of contexts?
+
* Session
+
* Users
+
 
+
Idea: What do we have to teach?
+
 
+
Take five fairly interesting plugins and look at which services they services. If we can cover they needs
+

Latest revision as of 14:07, 16 January 2009

Back to the top