<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Earlier we talked about embedding native browsers as a way of providing
better rendering of OSIS, which led serious consideration of Eclipse
technologies as a basis of the change. Others chimed in and asked
whether Eclipse's RCP (Rich Client Platform) was also appropriate.<br>
<br>
Over the holidays I have been playing with using RCP, working through a
tutorial (<i><u>eclipse Rich Client Platform: Designing, Coding and
Packaging Java Applications</u></i>) on major features. Here is my
impression:<br>
<br>
Cons:<br>
<ul>
<li>The footprint will probably be over 6M.</li>
<li>Using RCP can be done by hand in any IDE, but is really tied into
using Eclipse as a development platform. Eclipse provides wizards which
create the various entries correctly in a core xml file.</li>
<li>Since RCP is a framework, it will take some significant effort to
get into the RCP mindset. Personally, I found that a week of spare time
with a good tutorial is sufficient.</li>
<li>RCP is plugin development and presumes that our source is laid
out in specific ways.</li>
<li>Our JSword/Common jars will have to be repackaged as plugins.</li>
<li>So will third party jars. (To the extent that they have not
already been)<br>
</li>
</ul>
<br>
Pros:<br>
<ul>
<li>With the fairly clean separation of GUI and API in
JSword/BibleDesktop, it will be pretty easy to replace the GUI.</li>
<li>Complex widgets are better in SWT/JFace than in AWT/Swing. This
will get rid of some of our "work around" code.</li>
<li>GNU's Java can be used. (Eclipse on Linux uses it) This means
that we can distribute it as part of the install.</li>
<li>The splash screen comes up before the invocation of the JVM. This
allows for a seemingly faster startup.</li>
<li>The architecture of plugins means a faster start time to the
initial screen than what we currently have.</li>
<li>User preferences are pretty easy to implement. Specifically, we
can have the program remember settings on the view menu and also
placement and sizes of windows and their parts.</li>
<li>Provides cross-platform build, which can be automated, for a
larger set of platforms than we currently build. (Granted most are
Unix.)</li>
<li>With care, we might be able to use only Java Foundation Classes
which would allow for a smaller JRE to be used.</li>
<li>The placement of sub-windows is under the user's control. For
example, the Dictionary viewer can be dragged to the bottom or even to
a separate window.</li>
<li>The user can manage tabs as stacks or side-by-side or both. This
could be a starting point for "parallel" texts.<br>
</li>
</ul>
Issues:<br>
<ul>
<li>Basic issue: We already provide a framework which is also
provided by RCP. Do we abandon what we have, adapt it, or keep it? Or
do we adapt RCP to our paradigm? If it were only a GUI question then I
think the answer would be easy.<br>
Examples: Config/Preference, Progress Meter, Error Handling, Plugin
architecture, Internationalization, Actions, Class/Resource Loading,
....</li>
<li>Are the cons too big a hurdle?</li>
<li>Are the pros too great a gain that the cons are not too big a
deal?</li>
<li>Does not provide a cross platform installer.</li>
<li>We lose the following (unless we can figure out how to do them):</li>
<ul>
<li>Multiple Document Interface (we already discussed this and said
it was ok.) However, we do get the ability to have multiple windows
managed by a single desktop.</li>
<li>Parallel progress meter.</li>
<li>User overrides of properties held in jars. (Unless we keep our
Class Loader)</li>
</ul>
</ul>
Personally, I like what I have seen and am game to give it a try. My
time is limited during the next year, but I think I could flesh out
something in the near future. (I would like to see us do a 1.0 release
and a migration to SVN first, however)<br>
</body>
</html>