Ideas for improvements to MagicCube4d

Before next release:

 * Fix macro panel display bug


For each release:

 * Update copyright information to include years up to present year

 * Update verison in MagicCube.h and other files mentioned in the
   comment there


User interface issues:

 * Have some way of selecting a polygon and seeing all the other
   polygons that comprise that polygon's sticker.  This could be done
   with shading, outlining, etc.

 * Support multiple simultaneous views of the puzzle.  Alternatively,
   have a "back" view so that the user can see all the stickers at the
   same time without having to do any 4D rotations.

 * Implement "replay" so that a user can view a solution forward and
   see the puzzle from the same view that the solver saw.

 * Calculate faceshrink/stickershrink/eyew/eyez automatically based on
   n.  From Don:

   >   For an nxnx... puzzle, to get the stickers on a cubie to meet,
   >   set F=faceshrink in terms of S=stickershrink as follows:
   >	   F = n / (n-1 + S)
   >   For example:
   >	   n=3 S=1 F=1
   >	   n=3 S=.5 F=1.2
   >	   n=3 S=0 F=1.5
   >   I think it looks better with a small crack, e.g. S=.5,F=1.19.
   >   Other interesting values are S=.95,F=1-- this makes it look and act like
   >   a 3-D Rubik's cube (as long as you don't click on corners or edges).
   >   However, most of these interesting non-standard values
   >   show up the inadequacy of the depth-sort algorithm, even when
   >   sitting still.

 * (From Jonathan Vaughan) for n^4, where n > 3, provide an option to
   make outer hyperstickers transparent (wire-frame) so that the inner
   stickers are more visible.

 * From slashdot user: provide a way to disable beeping when clicking
   in the wrong place in a window

Windows issues:

 * Make "Save As" work

 * Support n^4 for n > 3

 * Support macros

 * Support marks

 * Add support for undo/redo through scramble boundaries (or remove
   from UNIX code if consistency is desired)


Logic issues:

 * Code a real solution algorithm.  Change the current "solve" button
   to "cheat", and have the solve button actually solve the puzzle.
   Look at Don's perl implementation.

 * In history compression, recognize pairs of moves that are invereses
   of each other and remove them.  (Do this recursively?)  Note: doing
   this at time of recording moves could result in unfortunate loss of
   information if one move is at the end of a pattern and the
   following move is at the beginning of the next pattern.

 * Have a way for the user to specify the number of random twists for
   a scramble through a dialog box; then always reset state before a
   scramble and insert a scramble boundary mark after a scramble of
   any length.


Things that would be nice but may not be worth the trouble:

 * Eliminate more of the code duplication between the Windows and UNIX
   versions.

 * Have a more general/uniform way of specifying preferences along the
   lines of the Java preferences conventions.  Right now, preferences
   are specified through a hodge podge of environment variables and,
   for the UNIX version, commandline options and X resources.

 * Ability to have a screensaver based on this