Detailed TODO list for alpha2 release

FileData and caching

In the original GQview design the internal modules didn't share any file data
except path. This was changed in Geeqie. Now there is a structure FileData, which
can hold various other information besides path.

This should be further improved by adding LRU algorithm for image pixbufs, exif and other
large data that can't be kept in memory for all image files.

LRU algorithm requirements:

• should scale from 10 entries for images to 1000 or more entries for exif data
• shold be limited by number of entries (exif) or memory size (images)

Is there any glib data structure that fits the requirements? (GList with O(n) is IMHO slow)
Re-using the LRU code in pr_queue and pr_tile_get functions is a bonus :)

Then we can use the data from FileData without any slownown to:

• create histogram from pixbuf
• rotate thumbnails by exif
• show images in delete/copy/move dialogs faster
• show more details in delete/copy/move dialogs (sidecars etc.)

Additionaly, there should be one centralized place to call stat() and maybe also open()
on fd->path - probably in file_data_new or related functions. The other functions should
use the content of FileData and the notification system.

API for sidecar files

This is partially implemented but it needs improvements and cleanups.

  base_file          (image.jpg)
    |--- sidecar1    (image.nef)
    |--- sidecar2    (image.xmp)

• Both base file and sidecars are FileData.
• Sidecar files are hiden by default, they are shown and/or selected on user request in filelist, iconlist should just indicate their presence
• Displaying functions will primarily display the given FileData, byt they can traverse the structure to reach more data (read xmp from the sidecar)
• external editors can be configured to get the selected file, the best fiting file from the group or the whole group
• internal copy/move/delete commands will operate on whole group, no matter if they are called on base file or on any of the sidecars
• there should be a function for ungrouping a particular file to copy/move/delete it separately
• selection in iconlist and unexpanded entries in filelist will select only base files
• selection of expanded entries in filelist will select also sidecars

TODO: create an API for these funcions

• grouping based on stat (done)
• grouping based on readdir (done)
• ungrouping selected files
• get prefered filetype (done on several places in the code, needs to be unified)
• copy
• move
• delete (do not break safe delete function)
• rename
• internal copy/move/delete should use this API

File change notification

Now geeqie goes through all lists of files in all windows and checks if the changed image
is in the list, see *_maint_reamed, *_maint_removed, etc. In some modules the images are not notified
at all.

With FileData structure we have other option - every module, that uses one particular FIleData, will add
it's own callback function to the FileData. When a file change is detected, these function will be called.
IMHO this might be more flexible.

Rewrite utilops.c

The code in utilops.c is quite obsolete, unreadable, buggy and ready for complete rewrite ;)

file_util_ funtions at the end of the file are probably the way to go, but needs to be updated for
external commands, sidecar files API and change notification.