Getting Data Into OpenJUMP

Over the last year or two I’ve written a couple of plug-ins designed to get data into OpenJUMP. The first of these plug-in imported GPX files, and the second plug-in imported survey point data from a delimited text file. I was allowing the user to access these plug-ins through a menu item under the “SurveyOS” top-level menu, but I recently decided it would be good if they could be located under the “File” top-level menu.

The problem with this is OpenJUMP automatically put the menu items for my plug-ins at the bottom of the File menu, which looks a little awkward.

So I decided to see how difficult it would be to allow access to the plug-ins using the built-in system for opening files to get data into OpenJUMP.

When OpenJUMP was originally written there was only a single menu item that could be used to import files. This menu item opened a file selection dialog, and the user selected the type of file from a list box at the bottom of the dialog box.

A couple years ago, we ripped out this rather simple system and replaced it with another one. I didn’t realize how much we complicated things with this replacement until I started looking at the code today. The current system uses a wizard framework to open different files in OpenJUMP. It implements a system to support “import options” or parameters supplied by the user. It seems to automatically build dialogs that allow the user to enter these parameters based on information from the plug-in that actually imports the data.

Here are the things I don’t like about the current way we open files in OpenJUMP:

(1) A large majority of the files we OpenJUMP don’t require any parameters or options. We just want to suck in the contents of the file. ESRI Shapefiles are an example of this type of file. I’ll bet the majority of the files opened with OpenJUMP are ESRI shapefiles.
(2) The current system limits the steps and validation of parameters that can be used to open a file. I can’t have my plug-in walk the user through a complicated (and custom) wizard, and I can’t really validate the parameters as they are collected from the user. So we are only serving a limited slice of the plug-ins that need to collect parameters from the user before we import data from a file. Only very simple parameters can be collected in our current system.
(3) The plug-in programmer has little or no control over the GUI that is automatically constructed to collect the parameters. In my experience automated GUIs are ugly and hard to work with. They are appropriate for some situations, but I don’t know if this is one of them.
(4) Our current system doesn’t seem to support different plug-ins that import data from files with the same file extension. For example: You might use my recent plug-in to import survey point data from a delimited text files, but there might be several other plug-ins that import entirely different data from delimited text files.
(5) The current system is more complicated than it needs to be. We’ve got at least 24 classes in three (3) different packages that are needed to open files. Should it be that hard?

There are some things I like about the system we currently have for opening files. It keeps track of recent files, which can be handy. But I bet we can do the same thing with something like the old system, and it won’t be nearly as complicated. The new system also allows plug-in programmers to get a GUI for collection parameters needed to open a file without too much work, but I bet if you are writing a plug-in for data import you can handle whipping up a simple GUI.

This is what I will work on implementing in BizzJUMP, and what I would like to see implemented in OpenJUMP:

Move back to a simpler system for importing data from files. This would be something similar to the old system. I’d like to see 2 menu items for each supported file format. One menu item for each file format will be used to import data, and will be found under File>Open File. One menu item for each file format will be used to export data, and will be found under File>Export File (or save file). Each plug-in programmer will place his own menu items for file import and export, just like other plug-ins place their own menu items.

I will create plug-ins for the standard file formats that OpenJUMP already supports:
ESRI Shapefiles
OGC WKT
JML
GML
JPG/PNG/TIFF

I think this will make our API easier for plug-in programmers that want to create support for new/custom file formats, and it will make our core less complex.

The Sunburned Surveyor