Larry Becker helped me figure out why Strings were getting passed as ContentIDs in OpenJUMP's rendering code. It turns out there are special renderers that need to be given a chance to paint on the LayerViewPanel everytime the LayerViewPanel.paintComponent() or LayerViewPanel.repaint() methods are called. For example, you have the FeatureSelectionRenderer, the BackgroundRenderer and a couple of others.
These renderers operate a little differently that the "standard" Layer renderer. This is because they always need to be given the change to paint. (The Layer renderer only needs to paint if the active task contains Layer objects.) The JUMP developers used an interesting "trick" to accomplish this. They added Strings to the list of ContentIDs stored in each RenderingManager. (These Strings are added in the RenderingManager's constructor.) A special renderer is then associated with each of these Strings. (For example, the FeatureSelectionRenderer is associated with the String "SELECTION".) Since the Strings are permanent residents of the ContentIDs list, the special renderers are always given a chance to paint. I want to change this system slightly to work with my pluggable rendering system. I will still add Strings to the ContentIDs list, but I will delegate the creation and return of the special renderers to implementations of my IRendererFactoryTool interface. This will preserve consistency and will also allow us to custimize things like background, grid, or selection rendering without recompiling OpenJUMP's source code? Does anyone see any problems with this idea? The Sunburned Surveyor (I won't be commiting any of these changes to the OpenJUMP CVS.) :] ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
