20050717 [1.N] Classes: RImage, load/store all EXIF info
20050717 [1.N] Classes: RImagesView, store ImgInfo in hashtable specific to current album
20050717 [1.N] Classes: RImagesView, expire hashtable ImgInfo for albums too old 

20050521 [1.N] Project: Add WIA reference
20050521 [1.N] Classes: RWiaImport, skeleton, basic import in currently selected directory
20050521 [1.N] Classes: Refresh image view after import

20050521 [1.N] Classes: RDirViewControl, ability to select an image
20050521 [1.N] Classes: RMainWindow, add info panel
20050521 [1.N] Classes: RMainWindow, display info from current selection

20050521 [1.N] Classes: RMainWindow, add rename panel (using regexp and replace)
20050521 [1.N] Classes: RRenameTool, skeleton
20050521 [1.N] Classes: RRenameTool, rename existing items from current dir using panel info
20050521 [1.N] Classes: Refresh image view after import

20050521 [2.N] Classes: RImage, implement cache with invalidation

Finished (by decreasing date):

20050722 [1.F] Classes: RImagesView, abort asynchronous operation when album changed or resized

20050721 [1.N] Classes: RImagesView, update singular image items when load completed
20050721 [1.F] Classes: RImagesView, start asynchronous load of image items

20050717 [1.F] Classes: RImagesView, display empty image placeholders
20050717 [1.F] Classes: RImage, load/store thumbnail, size, name (metadata)

20050712 [1.F] Classes: RImagesView, display image list
20050712 [1.F] Classes: RImage, implemented crude creation of thumbnail & get size
20050712 [1.F] Classes: RMainForm+Ex, Using RImagesView instead of WinForms\' ListView

20050626 [1.F] Classes: Created RImagesView (custom control, ex-RDirViewControl)

20050530 [1.F] Classes: Implemented IDisposable for RImage, RDir, RFSItem, RAppState
20050530 [1.F] Classes: RMainFormEx, display thumbnail in list view in large icon mode
20050530 [1.F] Classes: RImage, return Thumbnail for image (computed once only)
20050530 [1.F] Classes: RMainForm+Ex, load directory tree for current library
20050530 [1.F] Classes: RDir, load directories and images with filter
20050530 [1.F] Classes: RFSItem, properties Name, Parent, FullPath
20050530 [1.F] Classes: Added RFSItem, RDir, RImage skeletons with NUnit test

20050529 [1.F] Classes: Added missing LibVersion in RivetLib and RivetUI
20050529 [1.F] Classes: RMain added in RivetApp to load RivetUI.RMainModule
20050529 [1.F] Classes: Reorganized, adding RivetUI lib with all forms and RMainModule
20050528 [1.F] Classes: RMainForm+Ex, Load last current library at startup

20050524 [1.F] Classes: RAppState, create skeleton with Libraries and CurrentLibrary
20050524 [1.F] Classes: RLibrary, created skeleton with NUnit and AbsRootPath
20050524 [1.F] Classes: RMainFormEx, added location combo box management

20050522 [1.F] Classes: RMainFormEx, implement logic part of RMainForm
20050522 [1.F] Classes: Load/save window pos for RDebugForm/RPrefForm
20050522 [1.F] Classes: RPrefForm, empty skeleton extracted from Xeres
20050522 [1.F] Classes: RMainForm, create basic UI (tree control, base folder)
20050522 [1.F] Project: Use AppSkeleton

2.2. Milestone 1

2.3. Milestone 2

3. Notes

(Notes are given in chronological order.)

Basic architecture, from a class point of view:

• Preferences (Utils/RPrefs)
• Main Window
• Customized tree control
• May not need to be customized, start with a normal one
• DirViewControl
• Displays images and sub-dirs for a given dir
• Information panel:
• Displays details on selection
• RFileItem
• Generic description & manipulation of a dir/image
• Fields: Name, Parent (RDir)
• Ops: Move, rename, duplicate, etc. (rename only at first)
• RImage
• Represents one image file, with meta data and thumbnail.
• Inherits from RFileItem: Name, Parent, rename (override for cache)
• Fields: Metadata, Thumbnail (compute on demand)
• Cache: Metadata, Thumbnail
• For cache of thumbnail or data: Hash (aka System.Object.GetHashCode)
• Recompute and keep local hash when asked for
• Invalidate hash by ops (init, move, rename, etc.)
• Hash based on file metadata, file name & dir or file content.
• RDir
• Represents one directory with images and sub-directories
• Inherits from RFileItem: Name, Parent, rename (override for cache)
• Fields: Dirs, Images, AbsPath (live property)
• Cache: Dirs, Images (only live during a session?)
• RLibrary
• Inherits from RDir (override AbsPath to use BaseDir)
• Fields: BaseDir (abs path)
• DataCache
• Simply use a System.Collections.Hashtable

Note about UI:

• The initial implementation will use WinForms.
• I may want to consider a GTK# implementation later.
• As much as possible, UI should be separated from logic, that is all menu commands and things handled after selection should be separated in a non-UI specific class.

Note about cache:

• Ideally I want to compute some kind of hash for each image, to be able to store and retrieve cached thumbnail and exif info from a generic cache instance.
• If the hash must fit in System.Object.GetHashCode, it should be an int32.
• The hash could be based on file metadata, file name and abs path so that two different files have different cache entries.
• OTOH that means if an image or directory is moved outside of Rivet (explorer), all the cached info become broken.
• Another possible hash is to compute an MD5 or SHA1 on the file's data.
• It's more expensive than hashing just metadata & path
• Two images that are the same files should get the same hash, with is ok if we only want to cache data that are specific to the image and to the file.
• The hash doesn't change if the image is moved or duplicated, via Rivet or externally.
• Operations that alter the file must recompute a new hash and can't suppress the previous cached data in case it's already used (or it will need to be recreated)

Rivet stands for "Ralf Image Viewer, Exif and Transfer".

The absolute minimum for a prototype to do anything useful:

• A main window with:
• A field to select the library base
• A tree view
• Select one directory in the tree view
• Display images as thumbnail + name for that directory
• A tab panel at the bottom:
• One tab for an information panel on the current selection
• One tab for a rename panel on the current selection
• An import button or menu
• Ability to recursively load all directories
• Ability to display thumbnails of all images in a directory
• Thumbnails are recomputed on the fly (not cached) using Bitmap.Jpeg.
• Info for one or more image: size (pixels, mb), number of items
• All images sorted by date
• Simplified rename by regexp with select/replace (i.e. "*(a)" => "b\1".

Expansion:

• The library base field should become a combo with the recent library path used (stored in prefs.)
• EXIF info display should come after. It's not a priority at first.
• Extracting thumbnail from EXIF can come after.
• Thumbnail caching is not to be done in the minimum.
• Preloaded regexp patterns for renaming. Optional:
• Simplified rename patterns
• Memorize previous patterns
• Avoid reloading full directory after rename, only those image that changed.
• Ability to rename image or dir directory
• Ability to edit EXIF info
• Ability to change time/date of images via offsets

RMainFormEx override RMainForm and contains all the logic of the UI.

UI elements are declared (via the VS.Net resource editor) in RMainForm. As much of possible all actions performed by the UI are implemented in RMainFormEx rather than directly in RMainForm.

The goal is to separate the pure UI widget management from the logic of the window, in the hope it may be easier later to use a different UI kit (GTK#, etc.)

In a first test, RMainFormEx directly derives from RMainForm and thus will access WinForm widgets directly.

Note that the distinction used here is more or less similar to what VS.Net 2005 forces one to do with partial classes for WinForms and C# 2.0.

I setup my NUnit testing by having a separate Console Application that contains a main that invokes the NUnit testing framework on a set of listed libraries.

This separate project also contains the NUnit classes, so I have a library Foo containing a class Bar, there will be a class TestBar in the TestConsole project. Obviously TestBar will need to import Bar, thus the library Foo must be referenced in the TestConsole project. So far so good.

Unfortunately, I cannot reference an EXE this way. This means that I cannot directly have a NUnit class which test functionnality located in the main application.

OTOH when I created the skeleton I kind of arbitrarily though it would be good for every application (i.e. project producing an EXE) to have a sidekick class library (producing a DLL) and has much as possible move all the logic in the DLL and keep only the minimum UI in the main EXE. The idea was that once the application gets finalized, fixes will probably be either in the logic part or the UI part and maybe only one of those would need updating. Of course there's still a pretty tight coupling between those two.

So I just started doing just that, by experimenting with the following layout:

• A main class "RMainForm", deriving from WinForm.Form, describes the UI and contains all the callback for the UI. Most of these callback do nothing and call virtual methods.
• A second class "RMainFormEx" derives from "RMainForm" and implements the init and all the callbacks.
• A third class "RAppState" is used by "RMainFormEx" to embed, well... the state of the application, that is all the variables that contain resources, current selection, etc., that one would usually find in the main form as privates.

With this layout, I can have both RMainFormEx and RAppState in the library, only RMainForm needs to be in the application project.

Actually that's not even true as there is another class, RMainModule, which is the only one that really needs to be in the application project. It could reference RMainForm from the library. So later I may want to do that -- move everything in the library and only keep a minimal loader/boostrap/main entry point in the application's EXE. Right now this is mostly irrelevant.

Anyway I started with RMainFormEx placed in the main application project, next to RMainForm. Now I want to adapt the layout as described above. There's one more problem: I can't have RMainForm in the application and RMainFormEx in the library with RMainFormEx inheriting from RMainForm. The reason is simply because the library cannot reference the main application (it's an EXE, not a DLL, and anyway if both depend on each other that makes circular references... not a good thing.)

Basically I cannot have this:

 [  .Net  ]        [ Application ]     [   Library          Project      ]
                   [   Project   ]     [                                 ]

Windows.Form
     |
     +--------<|---------+
                         |
                   +-------------+                         +-------------+
                   |  RMainForm  |                         |  RAppState  |
                   +-------------+                         +-------------+
                         |                                        |
                         +---------<|---------+                   |
                                              |                   |
                                       +-------------+            |
                                       | RMainFormEx |- -(uses)- -+
                                       +-------------+
                  +--------------+            |
                  |  RMainModule |- -(uses)- -+
                  +--------------+

The solution is to introduce an abstract interface that defines the callbacks uses in RMainForm and implemented in RMainFormEx, like this:

 [  .Net  ]        [ Application ]     [   Library          Project      ]
                   [   Project   ]     [                                 ]

                                       +-------------+
Windows.Form                           | RIMainForm  |
     |                                 +-------------+
     |                                        |
     |                                        |
     +--------<|---------+---------|>---------+
                         |
                   +-------------+                         +-------------+
                   |  RMainForm  |                         |  RAppState  |
                   +-------------+                         +-------------+
                         |                                        |
                         +---------<|---------+                   |
                                              |                   |
                                       +-------------+            |
                                       | RMainFormEx |- -(uses)- -+
                                       +-------------+
                                              |       
                                              |       
                  +--------------+            |       
                  |  RMainModule |- -(uses)- -+       
                  +--------------+                    

Of course, it becomes just much easier to move RMainForm in the library and not use an extract abstract interface which is merely a workaround:

 [  .Net  ]        [ Application ]     [   Library          Project      ]
                   [   Project   ]     [                                 ]

Windows.Form
     |
     +-----------------<|---------------------+      
                                              |      
                                       +-------------+     +-------------+
                                       |  RMainForm  |     |  RAppState  |
                                       +-------------+     +-------------+
                                              |                   |
                                              ^                   |
                                              |                   |
                                       +-------------+            |
                                       | RMainFormEx |- -(uses)- -+
                                       +-------------+
                  +--------------+            |
                  |  RMainModule |- -(uses)- -+
                  +--------------+

This is still not completly satisfactory.

The thing is that the abstract interface does not add anything substancial except the need to declare callbacks in three places instead of two. The interface is a workaround to a project's reference issue, not a design issue. And anything that reduces the amount of code needed reduces the potential for errors, so it's a good thing.

RMainForm and RMainFormEx will always have a tight coupling, that is I would have used partial classes if I had been coding this in C# 2.0.

On the other hand it forces me to put all the UI stuff in the library whereas I said before I wanted to have only the "logic" part in there. So I want it in a library but not in the library. Hmm?

The obvious solution is to use two libraries:

• RRiverUI for all form classes.
• RRivetLib for all logic classes.

Now the RMainModule is accessed by the forms to get the global form instances via a centralized class rather than by cross-referencing them (i.e. to get the main form from the pref window, ask the main module about the form instead of having a global variable with the form.) This way I can avoid global variables completly by having static methods in the main module return the main form.

If I were to move all forms in the UI library, they couldn't access the main module class (since the library can't reference the application.) So I need to move the RMainModule class in the UI library too.

All what's left in the application project is a minimal class with a static main that instantiates the RMainModule class. This one in turn will create the main form. RMainModule should be a singleton class.

So at the end we get this layout:

 [  .Net  ]        [ Application ]     [ UI  Library ]     [   Library   ]
                   [   Project   ]     [   Project   ]     [   Project   ]

Windows.Form
     |
     +-----------------<|---------------------+
                                              |
                                       +-------------+     +-------------+
                                       |  RMainForm  |     |  RAppState  |
                                       +-------------+     +-------------+
                                              |                   |
                                              ^                   |
                                              |                   |
                                       +-------------+            |
                                       | RMainFormEx |- -(uses)- -+
                                       +-------------+
                                              |
                                            (uses)
                                              |
                                       +-------------+
                                       | RMainModule |
                                       +-------------+
                  +--------------+            |
                  |     RMain    |- -(uses)- -+
                  +--------------+

Now the only thing is that it is important to avoid cross or circular references between libraries. References between the libraries should always be able to be represented by a tree with no backwards links.

This is easily enforces since VS.Net will not let you reference a library that may cause a circular reference.

In this case we have the following dependency graph for the various libraires and applications:

LibUtils
   |
   +--------------------------+       
   |                          |
   |                          v
   |                     LibUtilsTests
   v                          |
RivetLib                      |
   |                          |
   +------------------+       |
   |                  |       |
   |            RivetLibTests |
   v                  |       |
RivetUI               |       |
   |                  |       |
   +-----------+      |       |
   |           |      |       |
   |     RivetUITests |       |
   |           |      |       |
   |           +------+-------+
   |                  |
   v                  v
RivetApp         TestsConsole

I implemented a bunch of stuff almost as planned today: RDir, RImage, both deriving from RFSItem (instead of RFileItem), loading directories and files (with a regexp filter), current selection in library and directory and displaying the images as a large icon list view.

That last one was a quick prototype hack. I will need to replace the ListView by a custom view. The ListView display only 8-bpp images by default .Net 1.1 and in the end I will want something more fancy than what a list view can do. But for a first prototype, it's more than OK.