[kepler-dev] Kepler user interface + relation to Recito

[Tim Van den Bulcke]

Hi all,

thank you for the enlighting comments.

I hope this discussion was helpful to all of you,

Tim.

Kenneth Evans wrote:

>Hi,
>
>I see that Eclipse is used to varying extents by the Kepler/Ptolemy
>developers.  However, I have not seen any evidence of expertise with Eclipse
>plug-in development.  Since I have been doing a lot of this, let me state my
>perspective.
>
>Eclipse is not a Java IDE.  Rather it is a plug-in manager -- that happens
>to come packaged with some Java development plug-ins.  You can take these
>and most of the other plug-ins out and be left with Eclipse core, which
>doesn't do much.  You can then put in what plug-ins you like.  If you would
>put in Python plug-ins, it would be a Python IDE.  If you put in plug-ins
>that allow you to order from Amazon.com (such exist), it would be an Amazon
>client.  If you would put in Kepler plug-ins, it would be a Kepler
>application.  It is this flexibility and extensibility that I believe is the
>real benefit of Eclipse.
>
>There are two ways to make a Kepler application using Eclipse.  There is the
>Eclipse Rich Client Platform (RCP).  With this you could make an application
>that looks and works pretty much like Kepler, but uses features from the
>Eclipse core framework (such as the dockable windows).  I can demonstrate,
>if you are skeptical, but not in this email.  The second approach is to make
>plug-ins for the Eclipse workbench.  Actually, if you do the former, you
>will get the latter for free.
>
>I think this is not so hard if, as you say, you have kept the model separate
>from the UI.
>
>In particular, you can use AWT via the SWT_AWT bridge.  This only takes a
>few lines of code.  They just have to be the _right_ lines.  Getting the
>right lines is the difficult part, but I think I have it worked out.  I have
>made several Eclipse plug-ins based on large, 3rd-party applications like
>Kepler, and they seem to work.  This is fortunate, because most Java
>development, especially the kind in which we are interested, has been done
>in AWT/Swing not SWT/JFace.  It is unlikely that the developers of those
>large packages are going to rewrite all that work in SWT.
>
>It turns out that a useful block for incorporation into Eclipse is a
>self-contained JPanel.  Given one of these, it is not hard to make it into
>an Eclipse editor or view.  Some applications are built around a JFrame
>rather than a JPanel.  I have found it convenient to take the content pane
>out of the JFrame and use that.  (The top-level container has to be an SWT
>Composite, roughly the equivalent of a JFrame, but it can hold Swing
>components.)  There are many ways to go.  I will repeat that a JFrame with a
>model behind it is the easiest to incorporate IMHO.
>
>The menus and some other interface elements need to be SWT.  If the
>application has been written so that action listeners call methods in the
>model, it is not hard to make SWT Actions that do the same thing.  It is not
>especially hard to write menus and make buttons: the real work is in the
>model, which should not have to change.
>
>I haven't looked at Recito.  I would think that this effort could best be
>done by the Kepler team, however.  With a little planning you can make an
>application that provides a standalone version (as it is now) and an Eclipse
>plug-in, or set of plug-ins, with the same code.
>
>The advantage of the plug-ins is that a user can use them in Eclipse as he
>wishes.  If he wants to do Java development of actors alongside, that works.
>If he doesn't, that works, too.  I look at Eclipse as an IE, an IDE without
>the D, something for users, just a way to organize their work, whatever that
>may be.
>
>BTW I have used the term Kepler in this email.  It is just as applicable to
>Vergil/Ptolemy or a combination, of course.
> 
>        -Ken
>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20071121/972420e1/attachment.htm