[e4-dev] Furthering the (Early) Adoption of Eclipse 4

["Stefan Mücke" <s.muecke@xxxxxxxxx>]

Hi e4 team,

in response to Mike Wilson's message, this mail is about what I think needs to be done to further the (early) adoption of Eclipse 4. I am writing this as an RCP developer and a plug-in developer since the days of Eclipse 2.0.

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


Best regards,
Stefan Mücke

Attachment: e4-doc-toc.png
Description: PNG image

Attachment: pixels-out-of-place.png
Description: PNG image