I've been working on inetgrating InfoNode's docking window framework
into OpenJUMP:
http://www.infonode.net/index.html?idw
This is the same docking window framework for Swing that Paul Austin
integrated into an older version of OpenJUMP. It no longer works with
the nightly build, so I'm taking steps to add the framework again.
(This is something I'm currently doing in my own fork, not in the JPP
SVN. The changes will be distributed in my own OpenJUMP flavor.)
While working on the integration of the docking framework I noticed a
change that I would like to make to the TaskFrame class. It currently
contains an internal class that listens for InternalFrameEvents. If an
internal frame is deactivated it replaces the current or "active"
CursorTool with a new DummyTool, effectively canceling the cursor tool
operation. I believe it would be better to call the cancelGesture
method on the current CursorTool before this is done. This will allow
the CursorTool to perform any clean-up needed before it is
deactivated. This could help avoid memory leaks, synchronization
problems, and other bugs.
Does anyone have a problem with or comments on this change?
Does anyone know why we set a DummyTool when the TaskFrame is
deactivated? Would it be better to implement setNoCurrentCursorTool
and hasActiveCursorTool methods on the TaskFrame class?
In my flavor of OpenJUMP I'll be reorganizing the TaskFrame class so
all of the constructors, public methods, protected methods, and
private methods are grouped together. I'll also be extracting the
internal class to an external class, and adding Javadoc comments for
all public methods of the TaskFrame class.
Please let me know if the community would be interested in seeing any
of these changes adopted into the core. I'll gladly wait until I know
I haven't broken the build before committing.
The Sunburned Surveyor
P.S. - I have attached the code snippet in question.
private TaskFrame(Task task, int cloneIndex,
final WorkbenchContext workbenchContext)
{
this.task = task;
//this.layerManager = task.getLayerManager();
this.cloneIndex = cloneIndex;
this.workbenchContext = workbenchContext;
addInternalFrameListener(new InternalFrameAdapter() {
public void internalFrameDeactivated(InternalFrameEvent e) {
//Deactivate the current CursorTool. Otherwise, the following
// problem
//can occur:
// -- Start drawing a linestring on a task frame. Don't
// double-click
// to end the gesture.
// -- Open a new task frame. You're still drawing the
// linestring!
// This shouldn't happen; instead, the drawing should be
// cancelled.
//[Jon Aquino]
// Should we cancel the cursor tool gesture instead, or in
// addition to this action? [2008-07-01 The Sunburned Surveyor]
layerViewPanel.setCurrentCursorTool(new DummyTool());
}
public void internalFrameClosed(InternalFrameEvent e) {
try {
// Code to manage TaskFrame INTERNAL_FRAME_CLOSED event
// has been moved to closeTaskFrame method in WorkbenchFrame
// I let this method because of the timer.stop [mmichaud]
// Maybe the WorkbenchFrame.closeTaskFrame should be moved
here...
timer.stop();
//memoryCleanup();
} catch (Throwable t) {
workbenchContext.getWorkbench().getFrame().handleThrowable(
t);
}
}
public void internalFrameOpened(InternalFrameEvent e) {
//Set the layerNamePanel when the frame is opened, not in the
// constructor,
//because #createLayerNamePanel may be overriden in a subclass,
// and the
//subclass has not yet been constructed -- weird things happen,
// like variables
//are unexpectedly null. [Jon Aquino]
splitPane.remove((Component) layerNamePanel);
layerNamePanel = createLayerNamePanel();
splitPane.add((Component) layerNamePanel, JSplitPane.LEFT);
layerNamePanel.addListener(workbenchContext.getWorkbench()
.getFrame().getLayerNamePanelListener());
}
});-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
