Re: [eclipse-incubator-e4-dev] RCP in E4

[Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>]

Hi Kai,

Thanks for your input, I think you raise very important points.  Do you
know if Siemens would be interested in working with us on some of these
issues?

I'll comment on some of your points below:

> - Can we reduce the complexity?
>  o Right now, after one week of training, a RCP newbie
>    just touched the very basic things of RCP.
>    This is one reason why many big industry companies have problems
> adopting RCP.
>  o A less complex application model
>    and a UI presentation model might help here,
>    but clean, simple and concise Java APIs all over the place are
> also very important.

I hope that our work area "architectural foundations" together with the
"Eclipse application model" will address this. I agree that it is important
to have clean and concise APIs, and additionally, I believe that we need
more consistency - things that have a similar structure should have a
similar API. I don't know how we can get there, but for example, we have
too many different flavours of objects-with-data-in-a-hierarchy such as
preference nodes, the extenstion registry, XML mementos, JFace tree content
providers, you name it.

> - Can we reduce the footprint?
>  o Do bundles like ICU (4.3MB) have to be part of the RCP core?
>  o Can we refactor the workbench bundle (3.7MB) and take optional
> things out of the RCP core?

I expect that by coming up with an application model, defined in terms of
services and interfaces, we will be able to componentize the Workbench, and
even allow replacing some of the implementations with ones that we don't
own. Also, I am hoping that p2 will make it easier to assemble the exact
pieces you want to ship with your RCP app, so that the current pain of
having to define your own RCP feature with the replacement bundle instead
of the full ICU4J goes away.

> - Can we focus on THE best practice of doing things?
>  o In the current RCP implementation there's very often more than
> one way how to archive the same goal.
>  o Can we integrate just the best practice into the core and provide
> an optional compatibility layer?
>  o Example: ActionSets vs. menu contributions (+commands & handlers)

Yes!

> - Can (and should) we provide a more customizable UI for the desktop?
>  o The ongoing discussions about a canvas based UI core are very
> interesting...
>  o For RCP UI customization currently we have the Presentation API,
>    custom SWT widgets, Equinox transformations etc.,
>    But besides that, current RCP applications look similar to the Eclipse
IDE.

I agree that we currently have a lot of accidental complexity that gets in
your way when you want to customize the UI. We should be able to reduce
that complexity by allowing styling similar to CSS. However, since there
are so many ways in which you can customize a UI, I don't think this will
ever become something that anyone can just go and do. Just have a look at
what it takes to define a CSS style sheet for a decent-looking blog, and
multiply by some factor that takes into account that an IDE is more complex
than a blog.

> - Should we integrate authentication/authorization better in the RCP
core?
>  o In the Equinox area there is some ongoing work to integrate these
things
>  o A standard user/role with UI support concept would be very
> helpful (see bug 201052)

Sounds like a very good idea. This is one of the areas that I don't see
covered in our list of work areas - it looks like this problem looking for
someone who wants to own it!

> - Should we integrate provisioning better into the RCP core?
>  o Currently Equinox p2 is integrated into Eclipse 3.4M6, and I like
> the p2 approach.
>  o But as of today, it is not so easy to reuse p2 in a domain
> specific RCP application
>  o Some of the provisional p2 UIs could be part of the public API in
> the RCP update story

This sounds like something that should be addressed in the 3.x stream, not
just in e4.

Boris