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.
E4/position papers/Kevin McGuire
Position Paper: Kevin McGuire
There are two main themes of what I'd like to see come out of e4:
- Make it easier to write Eclipse based applications so that more people can write them at reduced cost.
- Make Eclipse based applications stop looking like Eclipse based applications.
Make it Easier to Write Plugins
Eclipse has grown incredibly over the years. But a cost we've incurred is that it has gradually become more and more difficult to write Eclipse based applications. There's simply too much to know. We need to get back to basics so that Eclipse plugins are easier to write, and there is less a feeling of "fighting the frameworks". We need to widen the audience of who can build Eclipse plugins, and we need to make it cheaper to write them.
Eclipse Shouldn't Look like Anything
Eclipse is much like the original model T Ford, "you can have it in any color as long as its black". As I survey the Eclipse based applications, RCP or not, they all look, well, like Eclipse based applications. Eclipse provides much power through reuse of existing components and extension of frameworks. But my goal as an application developer is to build software that is as appropriate for my audience as possible. That audience could be anybody. However, many choices we made early on in Eclipse were with an IDE user in mind and just don't work well for other user types.
Why should my choice of technology so blatantly drive the UI experience? I'd like all that reuse and power, thank you, but the end result shouldn't betray the technology used to build it, provided I am willing to invest in specializing it.
If I look at say WorkdPress or Joomla, what I see is a highly energetic community producing components which deliver content, but also separately producing fantastic style sheets. With no, effort your blog can look ok. With more effort you can find a style sheet that you like and drop it in. With a little more, you can tweak the sheet. Or if you're really serious you can write your own from scratch. You can do all these things because the supporting technology (e.g. CSS) allows this separation, and because the components were designed to rely on it from the start.
The community has done some fantastic work in RCP applications, despite the limited and shallow variability we provide at the Presentation layer. Its not enough to simply extend the set of flags available. Applications should be assembled based on the set of UI components needed rather than relying on some flag to hide the element you don't want (e.g. perspectives). This is why the UI modelling work is important. Furthermore, the components themselves need to be engineered with this variability in mind. Preference keys or CSS style sheets don't help if a component hard codes its color choices.