I was chewing on my latest proposal to enhance the system Paul put into place for supporting custom TaskFrames when a question popped into my head:
Do we really want customized TaskFrames? The TaskFrame is a class, not an interface, and there doesn't seem to be a lot that could be customized, other than the layout of the child components. Even that would be restricted somewhat since any extension of the TaskFrame class has to provide a JSplitPane object from the getSplitPane method. I understand why Paul first made his changes (to test the InfoNode docking framework) but at this point I think we should "go all the way" or "not at all". - If we don't want to use InfoNode's docking window framework and we don't see other reasons to support TaskFrame subclasses lets clean the code up. - If we do want to use InfoNode's docking framework but don't want to support TaskFrame subclasses lets modify the single TaskFrame class and clean the code up. - If we do want to support TaskFrame subclasses lets build on Paul's changes and properly support a Factory pattern that can be used via the plug-in mechanism. I don't want to ruin Paul's ability to use the InfoNode docking framework with these changes, but he may not be using it anyways. I plan on using it, but I plan on doing this by making a fork of OpenJUMP that replaces the TaskFrame class. I think this might be cleaner than changing the core to support TaskFrame subclasses. Any thoughts? How about you Paul. What do you think? The Sunburned Surveyor ------------------------------------------------------------------------- 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
