User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
blog:eclipse_rcp_vs._rcplite_vs._naked_swt [2008/04/26 22:24]
djo created
blog:eclipse_rcp_vs._rcplite_vs._naked_swt [2014/10/17 22:08] (current)
Line 1: Line 1:
 +====== Eclipse RCP vs. RCPLite vs. naked SWT ======
 +When should one code in Eclipse RCP? When should one choose naked SWT? And when should one choose RCPLite, the new middle-ground?​
 +I tried to answer some of these questions in the following message I posted to the Eclipse.platform newsgroup. I thought it might help some other folks, so I'm presenting a slightly updated version of it here as well.
 +    Subject: Re: standalone SWT versus RCP
 +    From: David Orme 
 +    Date: Thu, 22 Jul 2004 13:33:02 -0500
 +    Newsgroups: eclipse.platform
 +    andrew mcintyre wrote:
 +    > Could somebody contrast the advantages/​disadvantages of going down
 +    >the standalone SWT development path versus the RCP path? Especially
 +    >with draw2d involved? ​ I'm leaning toward the RCP path because it
 +    >looks simpler but what do I know, I'm a raw newbie.
 +    RCP
 +    + Provides higher-level application framework than SWT; more
 +    productive if you need its features and like (& can accept) its
 +    general design approach.
 +    + Can include Eclipse'​s update manager if you need to supply software
 +    updates dynamically to clients. ​ This alone could be RCP's killer app
 +    if you're a corporate developer.
 +    + If your application'​s UI has to scale to huge, epic sizes (like
 +    Eclipse'​s UI has to be able to scale), RCP helps a lot.
 +    - For small to medium-sized applications that aren't updated often or
 +    are client-side-only,​ RCP is large, heavyweight,​ and slow.  All that
 +    dynamic UI stuff that helps so much if your UI has to scale to large
 +    numbers of features can just get in the way if you have small and
 +    simple requirements.
 +    SWT (by itself)
 +    + Small, lightweight,​ performant.
 +    + Is low-level. ​ You can code almost anything in it.
 +    - Is low-level. ​ Although you can code almost anything in it, it's so
 +    low-level it sometimes feels like you have to code everything in it.
 +    There'​s a third option not being talked about much, and that is the
 +    SWTworkbench RCPLite framework. ​ RCPLite is intended to sit in the
 +    middle-ground between naked SWT and Eclipse'​s full-blown RCP.  Here's
 +    roughly how it stacks up:
 +    RCPLite (http://​​devzone/​rcplite/​index.shtml):​
 +    + Small, lightweight,​ performant. ​ It's designed to be as thin a layer
 +    as possible on top of SWT and still provide application framework
 +    features.
 +    + Imitates the best features of Eclipse'​s UI and programming model and
 +    improves on a few of them.  Most notably these include perspectives,​ a
 +    unified view/editor model, and the Action framework (for menu bar and
 +    tool bar management).
 +    + Retains Eclipse 2.1's native look & feel.
 +    + A much simpler programming model than Eclipse'​s.
 +    - What you gain in simplicity you lose in UI scalability. ​ RCPLite
 +    isn't designed to be able to support as many features in the
 +    application UI as Eclipse can (yet it's designed to support a
 +    reasonable-sized app; for example, one could rewrite Quicken(tm) using
 +    it just fine).
 +    - No update manager for RCPLite (yet).
blog/eclipse_rcp_vs._rcplite_vs._naked_swt.txt ยท Last modified: 2014/10/17 22:08 (external edit)