Dynamic Interactive Visualization
Forum
Design reviews
Previous topic  |  This topic  |  Next topic
Previous article  |  This article  |  Next article

diva.canvas: comments, May 1st, 1998
John Reekie, 20 Jul 2001

diva.canvas: comments, May 1st, 1998

Email comments received after posting preliminary spec to the Java2D mailing list, and responses.

Shawn Rutledge


Date: Fri, 01 May 1998 19:09:00 -0700
From: "Shawn T. Rutledge" 
To: John Reekie 
Subject: Re: Structured graphics

Java2D is part of JDK 1.2, which also integrates Swing, so I'm surprised you didn't base your components on JComponent. As is they would be heavyweight wouldn't they? Also, "damage" is redundant; you can use repaint. In Swing, "glasses" aren't special, because you can call setOpaque(false) on any JComponent, and the result of that is that paint() will not automatically paint the background before calling paintComponent(), therefore it will be transparent. JFrames have a layered architecture, including a "glass pane" that is on top of everything, and you can add other layers. You can also build layered architectures inside JComponents, using things like OverlayLayout and JLayeredPane (but I'm not an expert on that yet). I don't see a lot of value in your event dispatching changes either; it's really not that big a deal to have to implement two listeners to get all the mouse events (I wondered why too, but it's not worth much nitpicking either).

Then there's the "figure", which is kindof a neat idea and many people think that they need such a thing, although typically when following the MVC pattern, you'd separate the view from the model anyhow. You can store a Shape in the model, and the view (subclassing JComponent) can have a paintComponent which calls draw(Shape) on its given Graphics2D. "Features" are a good idea; so far I don't know of any of this kind of support in Java2D. Again, you need to separate model from view and from control; if you allow the user to drag a feature with the mouse, that is control functionality, and should change the location of the feature within the "figure" model, not the view. The model then notifies the view(s). Always assume there will be more than one view/control combination for each model (users might want to see two different perspectives or zoom levels on the same drawing at the same time, and be able to edit in both windows). Animation is a good idea and I don't think is supported much in 1.2. Interactors appear to be a really good idea. This area is a very common weakness in many existing frameworks, and I haven't worked with any really complete designs for this sort of thing yet so I'm not quite as opinionated about what is the right way to do it. :-) But Taligent's CommonPoint seemed to have a decent design. BTW have you found any way to move the mouse cursor programmatically? This seems to be a Java shortcoming, and severely limits the kind of user feedback you can give in situations where you want to constrain the movement; you can constrain the movement of what is being dragged, but not the cursor itself.

A drawing package is a "poster child" for MVC; I'd consider it a must to separate the model, view, and control. There is a lot less blurring of those lines than there is in most "business" applications.

So in summary building a framework to make it easier to build drawing packages is a good idea, but yours doesn't have broad enough coverage of the needed features, yet, as well as arbitrarily transmogrifying things that already work well enough.

-- 
  _______                 KB7PWD @ KC7Y.AZ.US.NOAM   ecloud@bigfoot.com
 (_  | |_)  Shawn T. Rutledge            http://www.bigfoot.com/~ecloud
 __) | | \_____________________


John Reekie


From: John Reekie 
To: "Shawn T. Rutledge" 
Cc: johnr@kahn.eecs.berkeley.edu
Subject: Re: Structured graphics
Date: Mon, 04 May 1998 13:24:36 -0700

Thanks for your comments -- very thought-provoking! There is currently a compatibility problem with Swing and 2D, but I do intend to use Swing eventually. I wasn't aware of the layers support, so this is definitely something I will use. Thanks for the tip, I'm still gqetting up to speed on the 2D API, Swing is a little down the track... I oscillated back and forth on the new listeners -- I wanted a conceptual separation between entering and leaving, and dragging, especially for the interactors. But maybe you're right...

One thing I wasn't clear on: do you think every layer should be a JComponent? I am planning on using layers as figures embedded within a larger figure, for doing things like level of detail, zooming into different visualization spaces, and so on. I have been somewhat disconcerted by the complexity and performance (i.e. dismal) of Swing...

On MVC: the canvas is purely part of the view (except for the interactors sub-package). Each Figure has setModel and getModel methods to access its model. I think that it's important not to have things like Shapes in the model, since each view might render the model in a completely different way. The location, maybe, but not the appearance. Same deal with features: these support manipulation of the on-screen representation, but where that comes from is entirely up to the programmer. In an MVC-style architecture, it's coming via the model. I am trying to be careful to keep the scope of this package purely to supporting on-screen representation, without assuming particular applications other than "interactive 2D."

Shawn Rutledge

Date: Mon, 04 May 1998 19:56:35 -0700
From: "Shawn T. Rutledge" 
To: John Reekie 
Subject: Re: Structured graphics
I oscillated back and forth on the new listeners -- I wanted a conceptual separation between entering and leaving, and dragging, especially for the interactors. But maybe you're right...
If nothing else having two different models is extra clutter in a programmer's mind, because he or she will never be able to escape the official Sun event model anyway.
One thing I wasn't clear on: do you think every layer should be a JComponent? I am planning on using layers as figures
Well there isn't any higher base class for lightweight components, unless you impart the lightweightness yourself (I did this once, forget how...) I guess you could just have an object for each layer which stores Shapes to be drawn, and then in the layered component's paintComponent just draw all the layers' Shapes in order, but that seems like re-inventing the wheel to me. Containment isn't that expensive with Swing (but with peered components, each peer consumes a Windows resource, and painting the various layers involves a lot of going back and forth between Java code and native code; so that's why I think complex arrangements of components should be lightweight).
On MVC: the canvas is purely part of the view (except for the interactors sub-package). Each Figure has setModel and getModel methods to access its model. I think that it's important not to have things like Shapes in the model, since each view might render the model in a completely different way.
Aha, good point.
Previous topic  |  This topic  |  Next topic
Previous article  |  This article  |  Next article
Send feedback to cxh at eecs berkeley edu
Contact 
©2002-2018 U.C. Regents