Eclipse 4.0 SDK Review
Eclipse 4.0 Early Adopter Release was released at the end of July. The final few months of this release were a time of great churn ("Get 'er done !"), meaning that we had no time to review and/or modify the existing architecture but had to go with what we had.
Now we have a chance to go back and examine the decisions we've made and make whatever adjustments are necessary during the current 4.1 SDK development cycle. This includes not only code patterns, API and such but also packaging issues such as bundle names and dependencies...
Note, while we have this opportunity we have to act soon, we expect to start getting defects reported by the components and if we delay too long it'll just end up being 'too late' again.
This page is broken into various 'component areas' loosely alligned with the parts of the code that are affected by the decisions. For each we should determine the correct approach and then move towards it as fast as possible, the ouput from the discussions about topics on this page should be actual work items, defining the chosen implementation, who's going to drive it and some estimate of how long it'll take.
We know we need to handle legacy extensions in the compatibility layer but beyond that what's our story? The current e4 approach was to use 'descriptors' that would be added through the model 'snippet' extension. If we want to go this route we still need to flesh it out to include, at minimum, perspectives and windows.
Are there any existing extension points (org.eclipse.ui.menus, views, edtiors...) that it would make sense to support directly in e4?
What is the current state of the compatibility layer's handling of our current extensions?
What are the 'deltas' used for? This is in this section because the original discussions revolved around its use in managing bundles coming/going but there is no apparent use for this mechanism at the moment.
How do we contribute Addons?
E4 exposes its API(s) in ways that are fundamentally different from how they were exposed in 3.x (sort of the whole point actually...;-). The idea for this isn't to nail down the specifics of any of the particular API's but rather to define the patterns needed to implement a particular piece of API as well as seeing if we can determine heuristics that will help us determine which API mechanism is most appropriate to use to expose new capabilities.
Each of these needs to be both examined to determine if the capability it being exposed through the correct mechanism and to ensure that all API is 'discoverable'.
Context / Services
Access to services is through the context but:
Which ones are available?
Are we missing any?
Are there elements in the context that, while not services, should be considered API?
How do folks discover them? This is the important question, once we know how to properly define a new API service providing new ones should just be a 'rinse and repeat' crank-turning.
We need a clear explanation of how both active parts and selection are handled.
Looking at the context the other way around do we really need everything that's currently there?
DI is an extremely powerful and flexible mechanism. Its 'looseness' is both its greatest strength and potentially its major weakness. This is again mostly about how a user can determine what the valid annotations are and how they can be used.
How do folks contribute new anntations in a manner that makes them discoverable?
It's questionable whether or not tags should ever be considered API but they are available and may be appropriate to use in some cases. Should we determine that we want to allow tags as API then we need to determine the discoverability mechanism as well. Note that we currently don't handle nuances such as 'fixed' perspectives so we're either going to have to augment the model or use tags. The main advantage to using tags is that it allows the EMF model structure to remain constant while adding special case handling.
Known API-ish uses:
- Trim: "stretch" and "glue"
One of the design guidelines that the hierarchical IEclipseContext was to provide was "ask the context a question, and you will get back an answer appropriate for where you've asked the question".
- the selection service "selection" is available at the WorkbenchWindow level
- when executing a command from the application level, the "selection" should be available
- an editor can deal exclusively with its own selection, even when it is not the active part.
- many variables are managed at the WorkbenchWindow level, but need to be available at the application level for keybinding driven commands
- What's in the context?
- Why is it there?
- Is it API?
- Why so much churn (as defined by the number of RATs firing in various situations)?
Aside from just getting everything to work we also need to bring the 4.1 code up to snuff as far as being ready for enterprise level customers. This means having an implementation for all of the 'checkbox' items (NLS, BiDi, Accessibility, others??) but also to 'harden' the current code but providing better exception trapping and logging (with a special focus on trying to provide the most informative messages as possible).
We should do a general code review to ensure that hacks are eliminated (we have places where there is in-line code that should be moved into either the Model or Part services...). At the same time we should be on the lookout for places where we could safe up the code.
- should be around all execution of contributed code (as in 3.x).
- All event publications should be wrapped because they can indirectly invoke 'user' code
- Others ?
There are actually two different mechanisms used by the 3.x version of eclipse (and the current compatibility layer):
- Classes that extend the org.eclipse.osgi.util.NLS class: For eclipse this is used to define the 'static' strings used to construct dialogs or displayable error messages...This is a proven, viable technique and could easily be adopted by e4 developers.
- PDE support: This is more appilcable to the compatibility layer since it's already based on using extension points.
What we're missing is a story for how to handle e4 models that want their MUILabel information internationalized (label, tooltips and images).
Do we want to create a new TranslationService ?
Do we want to override the 'get' methods on MUILabel to 'automagically' return the translated info? (If so how do folks contribute translations for particular locales...?)
How should the locale be determined? (From the context?)
We need to support accessibility. This in general means:
- Keyboard support: Ensure that the renderers set up a reasonable tab order. Note that if we can do a good enough job with the 'Quick Access' then we would cover a lot of accessibility issues, especially if we had extra filters for navigation operaions.
- Screen Reader support: for us that means using IAccessible2 through the renderers. At minimum we will need to augment the model with; a specific 'accessibiliyPhrase' for an MUIElement (even containers need them) IAccessible2 also provides for the capability to reference a different widget from which the reader will retrieve the information. This is mostly used within dialogs to have a Text field/Table/Tree reference the actual 'label' widget so perhaps this isn't strctly necessary for e4.
- High Contrast: In e4 this should be possible through a specialized CSS...is it ? Special bonuses if we can get FireFox-like Ctrl + / - working against the workbench's fonts (old(er) guys like me use this all the time...;-)
We have to re-implement the Intro story. While we could re-implement the mechanism in the 3.x layer to make the code more consistent (i.e. getting rid of the IntroManager/IntroPart...) it may well be that this would be far harder than providing an implementation of these classes in the compatibility layer.
Do e4 RCP apps want Intro? Do they want it in its current form or a new one?
Once we have a more complete handle on what we have we should at least begin the task of writing the API spec(s)...
Stefan's quite correct...
A bunch of wiki pages with mostly internal discussions and to-dos is not sufficient. Wiki pages lack structure. They don't give you an idea of "what's in", and so you have to find out yourself; this costs way too much time. Currently, the available information is scattered all over the Web (blogs, tutorials, presentations, ...).
I think there should be a few short sentence about every important topic (e.g. model modification, selection listeners), and a few lines of example code. This should be possible to produce within one or two days of work.
To show you that I am serious about this point, I have compiled a documentation plugin that could be as a starting-point or as a source for inspiration (unfortunately, its mostly an outline so far).
See attached screenshot for the outline (table of contents). I have filed a bug and attached the plugin source there: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325654
We have to ship some form of model editor 'in the box' as part of the release. This likely means getting Tom's editor ready for prime time (NLS, accessibility...) and moving it out of the incubator. This is necessary to support e4's extension story if nothing else (See Stefan's comment about not having a PDE editor.
Compatibility Workbench life-cycle
This is something that needs prompt attention. The current way we define and populate the model (and the contexts) for the compatibility layer is antithetical to proper use of the model. We currently start with an almost empty window models and populate it using code in the WorkbenchWindow's 'setup' method. We also tear down large chunks of the model on close, only to recreate them on the next start. This is related to the dynamic bundle issues in that most of this work is being done to manage the dynamic bundles but the result is that we lose the ability to leverage the model itself.
The optimal solution here (if possible) would be to revamp our current life cycle so that the compatibility layer is implemented as one or more addons to the regular e4 RCP life-cycle. This will require us to re-examine how/when we create the compatibility instances of Workbench/WorkbenchWindow but this should be doable (maybe?).
We also need to take a close look at our legacy contribution managememt, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=325392#c5
There are a number of model changes being proposed. These are currently being covered using this defect: https://bugs.eclipse.org/bugs/show_bug.cgi?id=324957
We must be extremely careful when making changes to the model because we currently have NO story for how to bring an existing 4.0 model up to the 4.1 version. Alternatively we could implement the mechanism to do this but my suspicion is that it's non-trivial (at least) and may need significant lead time to get the design and techniques defined.
We've identified that we need a specific 'area' container to represent the Editor Area in the compatibility layer (since it, for example, minimizes or maximizes as one unit). Should we formalize this in the model or make it a specialized rendering of an MPSContainer ?
EMail comments (for reference)
Here's my take on the major areas that still require deep(er) discussion/specification, I'm leaving out the areas already identified as being 'needed' such as Welcome, NLS...since they're already on the wiki:
1) E4 Extension Architecture:
I put this one first because of its impact on the rest of the architecture. It's more relevant to the compatibility layer implementation at this point but e4 surely needs some extensions as well. Some of the issues with the current setup are:
- We currently create WorkbenchWindows in *code* rather than from some model 'template', this includes not only the Toolbars but the other trim elements as well. Note that we 'tear down' all out 'contribution' before saving the model, this is surely suspect...one ramification is that I cannot possibly implement re-ordering of tool bars since the info is removed from the model on close.
- I see no use of the 'deltas' file. I know we have discussed how this might be used but it currently seems to have no advantages over simply storing the model. Note that if we want a properly dynamic plug-in story the framework will have to be capable of handling new / removed extensions in a 'live' environment (aka 'hot oil change')...
2) Context (over) use:
While the context / DI make a truly powerful combination I think that we may be over-using it, especially as far as command management goes but also for basics like active part...we should likely review all of our current uses of the Context to assure ourselves that everything is needed...
I'm +1 for a general code review, looking to make sure that we haven't left behind various 'interim' fixes that are no longer necessary We should review all of our uses of 'tags' and decide what's API and what isn't Model review....if we need changes then teh earlier the better so we have more time to deal with the model 'upgrade' issues
A less code oriented note about the 4.1 SDK...perhaps we should put together a 'scoreboard' where we can keep track of what's been checked, what defects they found and who to contact. We could publish this on the wiki (or nor) but at the moment we don't have any way to measure our progress against 4.1...
1) probably related to Eric's #1. We currently read the extension points that make sense and convert them to model elements. Because of lifecycle, we've been creating them at inopportune moments (i.e. building a WorkbenchWindow around an MWindow model element, but after our primary model has been created). Should we be accessing extensions and model containers in some kind of merged fashion? Or should we be moving extension point readers into e4 model creation steps, so they're out of the compat layer all together.
2) we hard code a lot of creation into compat objects. i.e. WorkbenchWindow and Part initializeDefaultServices(). For services or information that we need to be level dependent, we should probably be using the Add-on mechanism to make sure event listeners are in place, and the creation of an EclipseContext at the appropriate model element to trigger the creation at that level.
3) provinding services and data to handlers in the EclipseContexts
3a) if you are adding data to your MPart context, it has to possibly be visible at 4 levels
- a popup menu in your MPart is an MPopupMenu with its own context, parented off of the MPart context
- the MPart context will be used by regular part toolbar or part dropdown menu (for "views")
- if the window toolitems or window menu items execute that command, they use the MWindow context and should be able to see the data
- keybindings get their @Execute and @CanExecute information from the MApplication context
3b) you can add a "service" 5 ways, each with different implications for when it is available
- when the MPart is created you can just set X.class.getName() => xInstance
- you can set X.class.getName() => context function, that will instantiate and return the xInstance when asked
- you can use the event broker to listen for a context being set, and then perform one of the above 2 steps
- you can provide a context function through DS which will then be available at the root context
- you can simply provide an OSGi service which will be available at the root context
4) rendering: visible. Our attribute doesn't quite mean what we'd like.
ex: toBeRendered - that's obvious, if it's false, the renderers can't see it. In the case of parts, that means there's probably a tab in a stack for it.
visible ... true == for most things that means it can be instantiated and we'll set widget.setVisible(true). visible ... false == it might be instantiated and setVisible(false). It might not be instantiated
it seems that we are describing 3 states: toBeRendered (can the renders see it), instantiated (can it have a widget), and hidden (can the user see it).
5) we went with a display filter for menus, so that on an SWT.Show we process a lot of MMenuContributions and visibility (and other stuff). It has 2 side effects that bear examining now
- if a submenu is empty, you must still have it there with "(none available)". Otherwise it will never be processed.
- a lot of inconsistency in ordering, positioning, and existence. This is because the menu mode structure is not stable at all. Another possibility would be to create the stable menu structure and then allow their rendering status or visibility to be updated on an SWT.Show.
1. Need to sort out how e4 parts will co-exist with 3.x parts. https://bugs.eclipse.org/bugs/show_bug.cgi?id=323506
2. Finalize the semantics of the shared area. https://bugs.eclipse.org/bugs/show_bug.cgi?id=321864
3. Need localization story for e4.
Major design break because ui.workbench depends on SWT which violates the core e4 design where only the renderers have a dependency on UI-Toolkits. https://bugs.eclipse.org/bugs/show_bug.cgi?id=319713
2. On Extension vs ModelDescriptors
I'm in favor of the ModelDescriptors because they extension points are a static thing you can't extend and we are in the end are nothing more than another Model (custom coded Descriptors) / MetaModelDefinition (.exsd). If we solve the generic modelfragment contribution (which doesn't need to know ids but uses XPaths (https://bugs.eclipse.org/bugs/show_bug.cgi?id=324954)) and MOST important invest enough time into the modeltooling ModelDescriptors are the better solution.
3. On NLS-Support
The first and most important questions is whether the translation is a decoration process or not which means the UI does not reflect the current model value but the renderer looks up the information using a workbench translation service. The SimpleIDE already has a very advanced translation implementation which we can take a look and discuss if this is the way to go (e.g. it would support on the fly switching of the language, ...)
4. Editor-Extension-Point replacement
SimpleIDE has an extended Ecore-Model with something very similar to what the editor-extension point provides in 3.x
5. On Delta Restore
Please note that not useing the delta restore has an direct impact on the Extension vs ModelDescriptors story because currently we simply add modelfragement-contributions to the Application Model on start up. If we are restoring from a complete saved model we need to merge in descriptors, handlers, commands, ... when processing the contributions.
There was an appeal to switch to 4.1 for daily development or bring up the issues if/why that's not possible. For me immediate blockers that come to mind are that I cannot assign key bindings, that I can't customize my perspectives and that it's very hard to see which part is active. Besides that, several of the bugs that I filed when testing for the 4.0 Early Adopter release are more severe than the severity indicates if the build is considered to be used for daily development and considered a true successor of the 3.x release. In that case any lost major functionality is a blocker. I think this might also be the reason why so few people start to use it and file bugs: they start it the first time, see all the lost pieces and then they stop using it.
Another real problem are the builds: 3.7 and 4.1 builds are not in sync and hence if we want to switch to the latest 3.7 build and 4.1 comes later we have to switch between versions and this is not easy since the workspaces aren't fully compatible (which is to be expected but an issue in this scenario). Just ask Olivier how long it took him last week ;-)
Here's my wish list for the next milestone:
1. SOURCE PLUGINS. Include the source plugins for e4 and EMF in the builds. I fully agree with Tom that this is a must-have. (Installing the source via P2 doesn't work for me.) See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=320768
2. DOCUMENTATION. Don't get me wrong. I am not asking for extensive and complete documentation at this time. But, I just think that a bunch of wiki pages with mostly internal discussions and to-dos is not sufficient. Wiki pages lack structure. They don't give you an idea of "what's in", and so you have to find out yourself; this costs way too much time. Currently, the available information is scattered all over the Web (blogs, tutorials, presentations, ...). I think there should be a few short sentence about every important topic (e.g. model modification, selection listeners), and a few lines of example code. This should be possible to produce within one or two days of work. To show you that I am serious about this point, I have compiled a documentation plugin that could be as a starting-point or as a source for inspiration (unfortunately, its mostly an outline so far). See attached screenshot for the outline (table of contents). I have filed a bug and attached the plugin source there: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325654 3. ADOPTER'S GUIDE. To make it easy for people to begin adoption, there needs to be some guide explaining what needs to be changed (or NOT) to adopt Eclipse 4. Some important questions to be answered:
- Which APIs will be deprecated? Which are considered old-style?
- Which APIs are not supported by the compatibility platform?
- Is the compatibility platform meant for RCP applications? (Why is there a "LegacyIDE.e4xmi" file instead of "LegacyWorkbench.e4xmi"?)
- Do RCP applications need to implement their own workbench if they want to be "native" Eclipse 4 applications? - If yes, do they have to implement all the nice features themselves they previously got for free (like DnD of parts and trims, ...)?
- How much adoption is necessary? Just make things work on the compatibility layer, or remove all references to old-style APIs?
4. TOOLING. I am wondering why Tom's tooling hasn't been included in the 4.0 release. Well, it might still be in incubation stage, but to me it doesn't look less mature than e4 itself. Just imagine the 3.x SDK would ship without PDE. How are people supposed to create their e4xmi files? Has the LegacyIDE.e4xmi file been created using the EMF editor? See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325656
Please note that so far I have not asked for a single feature XYZ. Adding more features is just a matter of time. What is more important at this time is, IMHO, that you communicate clearly what needs to be done to adopt Eclipse 4. (See especially my proposal of the "Quick Comparison" in the attached Adopter's Guide.)
Now I want to continue my list with some more technical concerns:
5. FIX SWT. If you really want to attract people and enable them to style their own applications, make sure that a number of bugs in SWT get fixed. There's a capable man out there, Emil Crumhorn, who knows how to make styling easy. He wrote the Ribbon example. In his blog post at http://hexapixel.com/2010/01/06/xaml-in-swt-and-where-the-ribbon-is, however, he states that he cannot continue to refactor his code into something easier, because of a number of bugs in SWT. Even Eclipse 4.0 is affected by one of the bugs (see attached screenshot), and I also have run into this bug using Draw2D/GEF. I think this should be done ASAP. Too much time has already passed. Known bugs to be fixed: - https://bugs.eclipse.org/bugs/show_bug.cgi?id=181676 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=297467 6. STARTUP PERFORMANCE. As an RCP developer, I strongly agree with Doug Schaefer (see http://cdtdoug.blogspot.com/2010/02/ok-eclipse-you-have-3-seconds.html) that start up performance is important. Eclipse 4 RCP should not be slower than Eclipse 3 RCP. Unless this is the case, I would think twice before porting my app to Eclipse 4.
(I hope to find the time to do some profiling work on this, especially for cold starts.) See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325655 7. TOOL ITEM RENDERER. Just try the following: 1. Open an untitled text file 2. Switch between the Package Exlorer and the text editor 3. Observe the delay of how the tool items get updated (500 ms are way too much) Now imagine that a whole toolbar (e.g. in a GEF/GMF application) gets enabled/disabled. The delay will be much more noticable (whole toolbar flashing with that delay), and this will make the UI *feel* sluggish.
I know that the tool item updater has been done for reasons of laziness. However, I think that using the "tracked access" feature of the contexts, it should be possible to get rid of this. Or, the periodic item updater could be replaced with a non-periodic one once the tool item has been enabled for the first time. See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325657