JFrac - by Dave Meyer (djm@cs.hmc.edu)

jfrac is an attempt to port the project I wrote in C with Gtk to do
fractal design into java, using swing.  The basic idea is to replicate
the existing functionality, and potentially add some new stuff, while
converting into a format that can be used across multiple platforms.

One of the features that is to be added is the ability to load modules
at run-time, which allow one to change the fractal computation function.
Thus, this should allow for easy construction of various different
fractal computations via a common interface (both API and on-screen-wise).

** Requirements **
+ The user shall be able to change the size of the image.
- The user shall be able to select by path the name of a class to
  use as a fractal function plugin.
+ The user shall be able to zoom in and out of the image by entering
  a zoom factor.
- The user shall be able to zoom into the image by selecting a rectangle
  on-screen.
+ The user shall be able to save the on-screen image to a file.
+ The user shall be able to change the color used for a given fractal
  index.
+ The user shall be able to stop an image render that is in-progress.
+ The user shall be able to exit the program.
+ The user shall be able to store the current fractal settings into
  a file.
+ The user shall be able to load fractal settings from a file.
+ The user shall be able to obtain a list of the index distribution
  visible in the current image.
+ The user shall be able to obtain a description of the current fractal
  method plugin.

** Future requirement possibilities **
- The user shall be able to work with multiple fractals concurrently.
- The user shall be able to switch from the current fractal to a different
  one (possibly new).
- The user shall be able to automatically resize the image to the largest
  available size within the bounds of the image viewport, sans scrolling.
- The user shall be able to set the centerpoint coordinates for the image.
- The user shall be able to get the current centerpoint and zoom factor.
- real-time modification of current colors:  keep track of the indexes
  in addition to the image, and then redraw in real-time (or near) as the
  user changes the value for a color on a control point.
- zoom in and out of the colormap bands, making each point a wider band
  as the zoom increases, up to a limit of (say) 5.  Can renumber as the
  zoom increases, as well; thus, more numbers would appear on the pallete
  as the zoom increased.  would be quite nice for working with delicate
  areas of the fractal computation.
- ability to reproduce a pattern of some length over some subset of the
  colormap (i.e., make a set of n colors which is repeated as posible
  across the remaining length of the colormap).
- support for numbers larger/smaller than the bounds of a double would
  be really nice, so that almost unlimited (or much *less* limited) zooming
  would be permitted.  BigDecimal comes close to what we want, but has
  a big problem:  very slow computation on large-scale numbers.
- advanced fractal plugins would be cool -- could have them be configurable
  with either some set of properties with their types and legal values or
  ranges, and descriptions of the values so used.  alternatively, could also
  have the ability to just pop up a component directly, so the people could
  construct their own configurators however they liked.  maybe could support
  both?  either way, could then have plugins which were capable of saving
  and reading state; these could be saved in a new version of the fractal
  file, post-colormap.
- far-fetched, and a long ways off, but it would be neat to allow the ability
  to use a distributed computing algorithm to compute fractals faster using
  network resources.  could write a fractal compute server which would have
  no graphic abilities, but which would compute from a network-passed
  fractal computation class for a particular range of values, and return
  the resulting indexes.  client could be configured to check for fractal
  compute servers on various machines in the local net, or perhaps to be
  given a list of addresses to use.  the means to divide up work would be
  an interesting challenge in and of itself.
- might be cool to allow auto-generation of frames, i.e., for a movie.
  could enter a zoom factor and the number of frames, and automatically
  generate all frames by smoothly zooming in to the given location.
  if we were feeling really clever, we could also track where the user
  zoomed in and moved about, and then generate all of the intermediate
  frames for them.  that would be a little bit more complex, although
  it wouldn't really be too bad -- just record the points that they
  observe along the way, and compute how to create frames automatically
  to get from each point to the next.
- would be kinda nice to have a status bar showing what the current plugin
  is (by name), what the current bounds on the image are, its center point,
  etc.

** Implementation Notes **
- the plugin loader should use reflection to verify that the class
  loaded implements the proper interface; if not, the loader should note
  the problem to the user, and prevent them from using the class as the
  module.
- the index distribution should list the distribution by both percentage
  and by absolute number of pixels.  it should list by ranges, since there
  are probably in the 1-10 thousands of distinct values.  the range cutoff
  should be specified by the user, with a default value to give 10 buckets.
  in other words, if there are 1000 indexes, the default range size should
  be 101, giving ranges 0-100, 101-202, ..., 909-1000.  the user should
  be able to enter 50, giving 0-49, 50-99, ..., 950-999, 1000.  thus, any
  level of detail can be made visible.
  - question: but what if they want to expand a particular range?  maybe
    we should also let them specify starting and ending, defaulting to
    0 and the max index value?

** suggested layout **

+---------------------------------------------------------+
|  top row: command menu (file ops, plugins)              |
+----------+------------------------------------+---------+
| zoom,    |                                    | index   |
| render   |     image, with scroll bars        | distrib |
| controls |                                    | display |
+----------+                                    |         |
| image    |                                    |         |
| size     |                                    |         |
| controls |                                    |         |
+----------+------------------------------------+---------+
|  bottom panel:  color mapping controls and color map    |
|  viewing pane                                           |
+---------------------------------------------------------+

** picture of Val's suggested colormap modifier

+----------------------------------+------------------------+
| (control point band)             | (idx) (c button) (del)^|
| (color band)                     | (idx) (c button) (del)||
|                                  |      ........         ||
|<--           ====            --> |                       V|
+----------------------------------+------------------------+

** current active list of todos **

- consider changing the colormap index distribution to a table rather
  than a text area
- consider moving percentages in index distrib to nearest .1%
- gridbag layout on the zoom/control/size sections
