Hi Johnny I'm replying to the gef dev list and cc-ing yourself and argouml. Could we keep this to just the gef dev list from this point forwards.
[To argouml devs - I'd be grateful if those of you not already on the gef dev list could subscribe to help out on the GSOC project there] I see two main areas that need abstracting out of GEF to allow a change of GUI. Swing/AWT I treat as one and java2d as the other. In this email I'm discussing the swing/awt stuff, I'll come back on java2d later. I think we need a full list of AWT/Swing classes that are used and a decision on whether they need to be abstracted and how to go about it. Some swing/AWT classes are fine to carry on using. For example the simple geometry classes such as java.awt.Rectangle and java.awt.Point. I think also javax.swing.Action is probably fine to carry on using. Any other GUI such as SWT should be able to wrap these using its own command pattern. However any action that presents a prompt to the user will require an abstract version that can be extended by some concrete GUI specific subclass. JMenu I'm not sure about, maybe this is simple enough to be fine also. We could carry on returning JMenu objects and expect some other GUI to simply treat that as a data structure and create its own native menu items from that. I'm referring to the kinds of items we return in Fig.getPopupActions(). The classes that obviously do need some separation within GEF are JGraph and JGraphInternalPane. JGraph will need an interface defined (how about DiagramPanel??) and the classes themselves should move (with deprecation) to org.tigris.gef.swing. Its those two classes that listen for MouseEvents and KeyEvents and propagates those to Diagrams, Layers, Figs, Selections etc and its those events and listeners that keep those classes tied to swing. So I'm thinking that we require an org.tigris.gef.ui.MouseEvent interface. The swing implementation of DiagramPanel should then wrap the actual AWT based event in our own event. I've done a quick diagram with ArgoUML to help stir up some discussion. Note that I've moved the existing functionality from JGraph to SwingDiagramPanel and a deprecated JGraph is left in place inheriting that functionality for backwards compatibility. For similar reasons FigNode is implementing both java.awt.event.MouseListener and org.tigris.gef.ui.MouseListener. But the methods of the awt mouse listener would be deprecated and the implementation of that interface removed at a later date. Anything currently implementing the awt mouse listener would have to be modified in the same way. Regards Bob. On 07/05/07, Jian Zheng <[EMAIL PROTECTED]> wrote:
Hi Bob, Looking into the code in GEF project, I found some graph related classes which use Swing/AWT functions in classes like Diagram, Figs(FigCircle, FigCube and FigDiamond etc.). I know you were suggesting to use SWT/SVG function. What I understood was that we would keep the functions/interfaces in the project and replace the GUI related logic by SWT GUI tool kit and/or SVG features. So we are going to use SWT for the alternative GUI logic and just add some SVG functions, like appendSvg() to support exporting SVG graphs? Was it the exact idea in your mind? Anyway, I was just thinking about another option but not sure if it's on the right way. My thought was about to introduce a virtual SVG layer using a SVG engine like Batik or svgsalamander SVG ToolKits, and then map the GEF objects to SVG Elements, for example, mapping Diagram to SVG Canvas, FigCircle to SVGCircleElement and FigText to SVGTextElement etc. We could benefit from this abstracted text-based GUI layer. For instance, rendering to Graphics2D or image is easily and it would be independent to any java GUI layer. Do you have any experience or ideas about this option? Could you please have a look at the above my thoughts and kindly give me some suggestions? Thank you very much for your help and sorry again about my delay. Best regards, Johnny
gefswing.zargo
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
