This shows you the differences between two versions of the page.
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. | ||
+ | |||
+ | <code> | ||
+ | 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://www.swtworkbench.com/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). | ||
+ | </code> | ||
+ | |||
+ | ~~LINKBACK~~ | ||
+ | ~~DISCUSSION:closed~~ | ||