[Digikam-devel] [Bug 126086] Besides the basic and full exif info I would like a page with selectable fields

Jens B.Benecke jens-bugs.kde.org at spamfreemail.de
Sat Jun 24 00:45:18 BST 2006

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

------- Additional Comments From jens-bugs.kde.org spamfreemail de  2006-06-24 01:45 -------
Looking at 0.9 svn current, the right sidebar IMHO needs to be cleaned up a bit anyway. (I just noticed that you have replied to this already. Just for the record, I'm posting this anyway, maybe for later.)

It is great that I can view all this information of a photograph. But the GUI clutter is far too big (IMHO):

- The right sidebar is unuseable on displays smaller than 1024x768 - there is simply no space. And it is not possible to make it small enough (it probably has a minimum forced size). Can this minimum size perhaps be taken out?

- Now there are *three* (!!) place where the tag tree is shown. It is not easy to see what the purpose of this duplication (triplication) is:

   a) we want to filter images per tags: select a tag
   b) we want to assign tags to images : drop images on a tag

That way, we only need one list with the tags. The left side tag list already does all of this.

- In the "Properties" sidebar tab, what is the difference between "File properties", "Images properties", and "photograph properties"? This is confusing. For example the "date/time" values that digikam shows. For any image, we have

 a) logical datetime values:
    (i) when the picture was taken;
   (ii) when the picture was copied on the computer;
  (iii) when the picture was (last) modified (from within Digikam?).

 b) physical datetime values:
    (1) EXIF:DateTime == DateTimeOriginal == IPTC:Date/TimeCreated
    (2) EXIF:DateTimeDigitized == IPTC:DigitizationDate/Time
    (3) file mtime
    (4) file atime

IMHO, (i) == (1), (ii) == (2) and (iii) == (3), and digikam should only care about the first two of these values.
For the file mtime: either it should be _always_ kept in sync with the datetime value in the DB, or ignored altogether (then one can use 'exiftool' to sync it with the EXIF datetime). But in digikam we are managing photos, not files. Right?

Here follows a proposal for the "Properties" right side tab. The idea is that the first (default) tab shows information that the *user* is interested in, but no technical details that are not related to the actual contents of the photo.


_______Photograph information:___________
    Name      : (file name)           (editable)
    Date      : xx.xx.xxxx xx:xx:xx   (editable)
   [Digitized : xx.xx.xxxx xx:xx:xx]  (optional, editable)

   Rating     : [* * * * *]           (editable)

   Tags       : xxx, xxx/yyyyyyyyyyyyyy,
                xxxxxxx/yyy, zzzzzzzzzz

   Comments: ________________________
   |                                 |
   |                                 |
   |                                 |

______Technical details:_____________
    Size      : xxx.xxx.xxx bytes
    Type      : xxxxxxxxxxx
    Dimensions: xxxx X xxxx
    Camera maker
    Camera model
    Aperture, Zoom, Flash, Exposure, etc.

(and all other EXIF/IPTC info that the user has selected)


The fields marked "editable" should look like text fields but change into an input field when hovering over them with the mouse. That way you don't acidentally change/delete them, and they are easier to read quickly (than a lot of input boxes).


- This new arrangement will unify the tabs "Tag filter" and "Comments/Tags" with the "Properties" tab -> less GUI clutter. Only three tabs are left - Properties, Metadata and Colors.
- "Folder" is not necessary, because we are working with Albums, not folders.
- Instead of "Modified" it should show the DB date/time (== EXIF/IPTC date/time) and (optionally) the date/time of digitization. These fields should be editable (upon click).
- "Size" is OK.
- "Owner" and "Permissions" is irrelevant for photos, unless you want to offer a photo LAN sharing system like Apple's iPhoto does. But that would require digikam to be network capable first. :-)

I would be willing to work / help working on this, but first I'd like to know what you think.



More information about the Digikam-devel mailing list