Problem Understanding
Since the auxdata, like color palettes and rgb profiles, is stored in a jar file they are not any longer accessible by a FileChooser. Even though the user has to be able to access these data and also to create new ones. So the old way of handling import and export is not applicable any more.
Requirements
Selecting Auxdata
For the user it is not important where the auxdata is located. So there is no need to use full pathes to the auxdata files as they are currently used by the FileChooser. A simple list of all in the current context available auxdata is sufficient. For the user it is also good to know which auxdata is currently selected.
Importing Auxdata
The user must be able to import auxdata. This auxdata is located on the filesystem (what about auxdata located on the web). After importing some auxdata it must be the currently selected one. It must be available after a restart of VISAT as well.
Save Auxdata
If the user saves some auxdata it is sufficient to ask for a name of the auxdata and store it at a pre-defined location. The saved auxdata must be further available to the user.
Exporting Auxdata
If the user wants to export the current state as auxdata he must be able to choose a file location. But the exported auxdata must be further available to the user.
Deleting Auxdata
The user must be able to delete auxdata created by him self. The auxdata provided by the system are not deleteable because they might be in a jar.
Possible Approaches
General Handling of Auxdata
On the one hand auxillary data is provided by modules and on the other hand created by the user. The user created auxdata is stored in the user directory.
Also File shouldn't be used anymore for loading auxdata. All loading has to be done by URLs or Streams.
CERES Framework Handles Auxdata
The CERES Framework can collect all auxillary data from the registered modules and provides a central access point to the auxdata. This enables a modules spanning auxdata usage and modules can provide auxdata to other modules.
The auxdata should be placed in pre-defined location within the module or the location is defined in the module.xml.
The problem of course is that this approach does not work if the framework absent. The context the modules are used in has to provide its own approach to handle auxdata.
Each Module Handles its own Auxdata
Modules can only scan their own auxdata and auxdata of modules they depend on, but not modules which depend on this module. This approach works in each application context, with or without the CERES Framework.
Central Location in the Application Directory
All auxdata is stored in a central location in the application directory. Auxdata shipped with the BEAM installtion can be directly installed to this location. Auxdata provided by modules installed later must be handled by a post-installer of the CERES Framework which copies all auxdata to the central location.
Handling Auxdata in the UI
Open a Auxdata Manager Window
The user needs to open another Window which covers the current Tool Window and/or the Product View.
The Manager Window needs a preview button so the user can see what effects the selected auxdata will have (really).
Modal
Settings cannot be changed by the user during the window is opened (e.g. slider in contrast stretch)
Non-modal
To many windows flying around. Settings can be changed.
Place a Auxdata Manager Component into the appropriate Window.
Everything can be done in place. It is easy to access and preview is done on the fly. The size of the window increases a little bit. The upper part of the RGBImageProfileManager can serve as an example.
Use Cases
Color Palette Example
Use Case Environment
The user has an opened ProductView and the ContrastStretch is also visible.
Selecting
If a palette is selected the user wants to see what effects the selection will have.
We have 3 options:
- Display the changes in the product view
How to undo the preview? In a Manager Window it is possible to undo on cancel. In a Manager Component we need an undo button. - Display the changes by a preview image
No need to undo the changes. But this approach needs more space on the screen. To reduce the needed size we can use a panel which is only shown while the preview button is pressed. - Display a small iconyfied image in the list
The advantage is that the user always knows what effects each palette will have but it may take some time to create all preview images. Or some general image is used and the preview is stored with the palette. (This approach is not applicable to RGB profiles. Bitmask definitions are also diffferent, but these are sufficiently described by theire description.
For pins and rois a preview is also not applicable.)
In cases 1 and 2 it is possible to work on in the preview state, without clicking Apply. Only in the modal window this is not possible.
Importing
The user can import a new palette which is aftwards the selected one and also in the list of available palettes. A preview is shown for this palette.
Saving & Exporting
In most cases the user just wants to save the current palette. Only if the user wishes to forward the palette to someone else he wants to export the palette.