The welcome page is created using the Welcome Framework (sometimes called the Intro Framework). There is not one of the friendlier APIs and I can’t really give you step by step instructions in these comments.

The best you can do is do a Google search on “eclipse welcome framework” and try to piece things together. Also, here is a link that might help:

http://www.eclipse.org/eclipse/platform-ua/proposals/shared-intro/shared-intro.htm

I hope this helps,

— Patrick

@Josh: I have looked at Eclipse Riena, and I like lots of it, but once again, how does this technology mix and match with everything else? Not well it seems.

Josh, we are currently investigating how to allow Riena to “mix and match” better with existing RCP code-bases. One goal is to enable developers to use parts of Riena instead of forcing them to adopt “all or nothing”. Another goal is to refactor Riena so one can easily use GUI tools like SWT Designer with our code base.

Regards,
Elias.

>>SWT Designer is nice…but it doesn’t beat Matisse

SWT/Swing Designer beats Matisse under almost any conceivable criteria (other than cost). Designer is easily the most advanced and most powerful Java GUI development tool available from any source. CodeGear recently reviewed all available commercial and open source GUI builders (including Matisse) and selected Designer as their new GUI builder for JBuilder 2008 (even though they had to pay extra to OEM it).

Designer is also well regarded as having the most flexible and clean code generation of any GUI builder in the industry (it even won the Eclipse Magazine’s Reader’s Choice Award for best Eclipse Add-on partially based on that fact). It can emulate the code generation of any other GUI builder (including JBuilder, Matisse, JFormDesigner, Jigloo, VA Java or the Eclipse Visual Editor) or just about any other style you might like. The product also has a very powerful reverse engineering parser which means it does a very good job of reverse engineering code generated by other GUI builders or by hand…something that tools like Matisse can’t do (even with their own generated Java code). Try to hand-edit or refactor the code generated by Matisse and see how far you get.

While Matisse has some nice features (easily matched by Designer), it is very primitive under the covers as it requires a parallel and redundant .form file. Not only is this a redundant duplication of information already in the .java file, it is also dangerous as the .form file is easily lost and can get out of sync with the associated .java file. Designer has rescued dozens of major Java projects that were unable to edit their GUIs after losing these .form files. That approach is also an extreme example of vendor lock-in that ties you into using just a single tool. Designer, in contrast, can read and write code generated by any other GUI tool.

-Eric

Thanks for the comment. I definitely agree that RCP is not *the” UI for Equinox. I guess at the moment it’s the client-side UI for Equinox. But as you allude to in your comment about e4, the distinctions between client, web, mobile, etc. are going to be breaking down in the next few years and we may get to a point where we have an Equinox UI toolkit that is simply rendered on different platforms.

To be honest, I wouldn’t mind seeing RCP as distinct entity disappear in place of a brand that encompasses all the modular UI technologies (RCP, RAP, eRCP). I’d have to rename my website, but oh well…

— Patrick

I’ve found that users who do not understand (or need) modularity are often frustrated by RCP. These users often wind up asking themselves, “Why am I not using Flex, etc.?” Users want to know why they have to use plug-ins and extension points or why is the build process so complicated? If you haven’t bought into modularity, then there really is no good answer to these questions.

I think in the past we’ve been dancing around this issue because Java modularity itself was not well understood by the developer community. As modularity becomes more mainstream, we have a great opportunity to leverage RCP in this space. In a sense, I see RCP as a technology that is waiting for it’s time. It’s our job to make sure that RCP is ready when that time comes.

— Patrick

Note that the “Equinox” here does not necessarily mean just the project. It is more a label for the set of technology at Eclipse that is highly modular and broadly applicable to runtime scenarios. UIs, web, OSGi, provisioning, communications, modeling, …

RCP as *a* UI for Equinox is certainly a reasonable way to look at it. As *the* UI it doesn’t work. There are others like RAP, eRCP and assorted technologies like GEF, Zest and the various 3D work. e4 of course is also coming to play.

Summary: I like the direction you pointed. What we are seeing is the third evolution of Eclipse – from IDE platform to Rich Client Platform to Application Platform. Figuring out how to talk about it is part of that evolution.