Event Flows:

Reports Pane:
  User clicks tree: TreeSelectionListener in ReportsPane
                    calls reportSelectionManager.setReportSelection(imageFile, featuresFile).

            featuresFileTypeModel fires changed event and has FeaturesFileTypeModel.FileType.

      FeaturesPane has featuresComponent and referencedFeatuersComponent
      that provide featuresModel and referencedFeaturesModel instances of FeaturesModel.
      They both respond to featuresFileTypeModel changed events to reload their features
      using FeaturesParserThread.


  User clicks a feature line in featuresComponent or referencedFeaturesComponent:

       if the feature line is HISTOGRAM: set filter in referencedFeaturesModel to featue line text.
       if feature line is ADDRESS or PATH: set image model with feature line.


  Image Model gets set by selecting a feature line in featuresComponent
                    or by selecting a feature line from history or bookmarks:

       Thread reads image, produces data structure ImagePage, and provides that to ImageView.
       ImageView calculates the renderable image view and fires an ImageView event.
       User highlight changes also change ImageView.  See ImageView for event types.

------------------------------------------------------------
Choice of Java jar launcher launch4j over winrun4j:
http://stackoverflow.com/questions/9330209/whats-the-best-way-to-start-java-applications-on-windows-7
Problems with winrun4j: 1) JVM used, 32-bit or 64-bit, is determined by launcher used,
32-bit or 64-bit, and can be confusing to the user.  2) I believe a signed winrun4j launcher
can be stolen and reconfigured to launch any Java program, so I don't want to ship one.

Choice of msi installer nsis over WiX:
WiX is harder to install for use:
WiX requires interaction to install, which is an inconvenience.
Also, WiX requires Mono and Wine for its compiler and linker.
new bulk_extractor version names required a new configuration script
Installation and removal are made atomic, which prevents a broken state.

nsis is easy to install and use:
nsis is a Fedora package.  The nsis script is good across new bulk_extractor versions.
The uninstall process can fail, leaving residue.  The uninstaller checks to make sure
bulk_extractor and BEViewer are uninstalled, and installations go into separate paths,
so this limitation is not expected to be an issue.
------------------------------------------------------------
Using svn:ignore to set SVN ignore file list for directory:
From the desired directory (dir .): "svn propedit svn:ignore ."
Note: define in .bashrc using editor that takes the terminal (e.g. vim): "export SVN_EDITOR=vim"

------------------------------------------------------------
Validating the distribution: make distcheck

------------------------------------------------------------
Conditionally make java_gui AND introduce doxygen:
http://chris-miceli.blogspot.com/2011/01/integrating-doxygen-with-autotools.html

------------------------------------------------------------
Compile and run using multiple Java compilers:
Install OpenJDK and libGCJ.
Type "java -version" to see which Java is in use.
Type: "alternatives --config java" to select which Java environment to use.

------------------------------------------------------------
EXIV in bulk_extractor: from 7/2/12 10:59:

On 06/26/2012 02:55 PM, Garfinkel, Simson (CIV) wrote:
> I didn't want you to remove exiv2. I just wanted you to remove the warning. …
>
> Let's make the rest of the changes next week. Specifically:
>
>
>> 1) HAVE_LIBICONV
>> I think I can get rid of HAVE_LIBICONV.  This should mean that mingw no longer needs iconv.dll or libiconv-2.dll.
> Yep. Let's get rid of it.
>
>> 2) HAVE_LIBEXPAT
>> I think I can get rid of HAVE_LIBEXPAT.  This should mean that mingw no longer needs libexpat-1.dll.
> Keep it. I want to replace my hacky XML parser with expat.
>
>> 3) GNUC_HAS_DIAGNOSTIC_PRAGMA.  This is used outside of exiv2 and should be retained.  It should be in its own section titled "Check GCC for diagnostic pragma".
> Agreed. After JUNE 30.
>
>> 4) LDFLAGS="$LDFLAGS -shared-libgcc" # allows exiv2 to throw an exception that's caught elsewhere
>> If this flag is just for exiv2, this flag should be removed.
> Agreed. Let's get rid of the flag after JUNE 30.
>
>> Shall I make these changes, or would you like me to leave this alone until next week?
>> Thanks,
>> -Bruce
>>

------------------------------------------------------------
Fully support Forensic Path (v1.4):
There are two primary deficiencies:
1) Forensic path is displayed in a non-standard manner.
2) Features from recursive directory scans cannot be browsed to.

The fix was to remove path type modality (absolute path, embedded path,
histogram entry, recursive file type) and track the Forensic Path
as a string and to track the Report image file and the Actual image file.
This impacted the Readers (EWF, Serialized, Raw), so all Java readers were
removed and only the bulk_extractor reader remains.  The bulk_extractor
reader is the only reader that manages recursive forensic paths anyway.

Since jlibewf was removed, its requisite logger, log4j, was removed.

Since bulk_extractor does not export E01 information fields, the "get info"
capability, available only in jlibewf, was removed.

------------------------------------------------------------
Trouble with modal windows requiring focus but being hidden:
Solution: Use setAlwaysOnTop for modal dialog boxes.
When running processes ask Swing to open a modal dialog box, an open modal
window can get covered, even though it has modal focus, resulting in the
appearance of a GUI hang.  To mitigate this, all modal windows must call
setAlwaysOnTop.  Although they unfortunately paint above other applications,
they do remain visible, which is a requirement.

------------------------------------------------------------
Working with ListSelectionListener:
When Java's JList data listener sees a data model change, it changes state
of the data listener.  The JList component should not change state of the
selection model when the data model changes, this is a violation of
responsibility.  Here is how it is disruptive for my use case:

When the list model changes, it fires events to its listeners.

My listener runs first, and sets the selection in the selection model to the
last item in the list because in my use case, items should be selected when
they are added.

The JList listener runs second, and changes the selection in the
selection model on my behalf in file javax/swing/plaf/basic/BasicListUI.java
function intervalAdded(), causing it to roll past the end.

JList should not modify the selection model when the data model changes.
If the selection model is to track the data model, it should listen to the
data model directly.  If the selection model is not to track the data model,
as in my use case, the JLabel, which listens to the data model, should leave
the selection model alone.  But it does not.

The fix:
1) I add an item to the data model.
2) The data model fires its intervalAdded event, which causes JList
   to corrupt the state of the list selection model.
3) I select the last item in the list in the selection model, which is the
   required functionality for my use case.

------------------------------------------------------------

