[KimDaBa] Just-after-initial thoughts

Jesper K. Pedersen blackie at kde.org
Thu Feb 26 07:43:35 GMT 2004

jedd <jedd at progsoc.org> writes:

|  Howdi,
|  Okay .. I've started (4415 pics done, 2300 to go) on the arduous process of
|  importing my image directories.  It's going really well so far, I'm happy to
|  say.   I think I have as much taste in selecting software as Jesper has skill
|  in coding it.  </ObCompliment>
|  Anyway, I have two questions and a few wishlist items.  Again it's quite
|  possible that I've missed things that are already there but hidden, so
|  I apologise in advance for anything that fits that category.
|  Question 1
|  Why is there a separate way to modify a single file or to modify multiple
|  files -- can't that be determined by whether you've selected one or more
|  files?  Or is it a safety feature so you don't accidentally modify more
|  files than you think you are?
Please see

|  Question 2
|  How does everyone cope with managing things that are conceptually
|  sub-sets of information?  I'm writing very wordy descriptions in the
|  keyword area, like 'event - 20030606 - dvd night at bob's', trying to
|  keep a consistent format for descriptions, and I've set up a custom
|  option group for the content of only the 'arty' photos (for example),
|  and it seems a bit unweildy, but I can't think of a better way ... ?
I'm not sure I understand the question, when you say subset of .. would
this help you:

|  Wishlist Items
|  Startup information about new files:
|  Rather than simply saying 'New images were found - shall I trust
|  their timestamps?' how about something like --
|  -- simply listing the sub-dirs showing where the new files have
|  been found.  This would give the user some context so they can
|  decide whether to trust or not,
|  -- mention the total number of new files
|  -- check if there's EXIF data in any of them (I've tested this by adding
|  a small number of files that definitely contain EXIF date information,
|  and it still asks).  At the least, clarify to the user that if they select 'No'
|  then EXIF data will be honoured, but then it'd be nicer if it told you 
|  if the EXIF data was actually there first.
|  -- show all new files and their file-time-stamps and their EXIF dates.
|  This could be a huge list, I know, but shouldn't be too time-consuming
|  to calculate & display.
I love that idea, unfortunately I'm afraid it would require quite a
redesign of what goes on below the hood. That dialog is shown the first
time I see a new image, and not when I've found them all.

|  Keep image viewer on-screen while editing properties:
|  This would make it easier when you're adding the names of people
|  in 'busy' photos.  The ThumbNail on the properties-dialog is too
|  small to be useful once you get more than 5 or 6 people in a photo.
drag off the window with the thumbnail view, and resize it. Seems like I
have a candidate for a FAQ here ;-)

|  Next-image button while editing properties:
|  Accept changes and takes you to the next image - rather than having
|  to find and select the next photo with the mouse and then ctrl-1 to
|  edit its properties.  Should make it nice and fast when adding new pics.
Select a bunch, and press Ctrl-1 (see URL above)

|  Put focus to Persons-widget when opening properties:
|  I gather that the tab-order is a function of the order that widgets are
|  created, but hopefully making the cursor start in the text-entry field
|  is easy.  This would reduce the mouse-dependency a smidge.
Tab order and focus is a mess on that page, something that is hard to solve
since you can move the content around. Its on my bug list, so hopefully one
day I'll find a good solution - it bothers be a lot too ;-)

|  Remember window positions:
|  On startup, kimdaba reverts to its (hard-coded?) original window size,
|  which is way small on my monitor (1600x1200).  Worse yet, the properties
|  editor reverts to a painfully small window, and even worse, the 'extra'
|  properties dialog is positively tiny, and isn't placed next to the main
| dialog.
Added remember windows size to TODO.
Regarding the image config window, choose Options -> Save current window

|  Options | SaveCurrentWindowSetup - doesn't remember the size of the whole
|  dialog, or the widget sizes within that.  I think I saw something about you
|  intending to embed extended properties dialogs into the main dialog, yes?
|  That'd solve a lot of problems.
It do not remember the size of the overall window, but it should indeed
remember the size of the individual parts, though that might be broken by
the overall window not being restored to its original size.

|  Maintain highlighted thumbnail after image edit:
|  After editing the properties of a file, the thumbnail view then un-selects
|  the image you were working on, which makes it tricky to identify the
|  next image on a busy screen with small thumbnails of similar pics.
|  It'd be easier if the selection is retained on the thumbnail view, when
|  you return from the properties editor.
It is indeed keept, I think understanding Ctrl+1 above will help you if
not, please tell me what you do.

|  Image information on hover:
|  I know you don't like having a pop-up box showing you information, and
|  I tend to agree -- it takes up lots of space and hides other images.  But
|  how about an extra line in the status bar, where it shows persons/location
|  etc for the thumbnail under the mouse?  Makes it easy to work out if you've
|  updated the pic yet, too.
Try Ctrl+T (Help -> show tool tip on images)

|  Time stamp information:
|  Show the time-stamp as well as the date-stamp for files.  I don't know
|  if it'd be useful to be able to search for photos taken at a particular
|  time ('show me all photos that *might* be sunsets' perhaps? ;) .. but it'd
|  certainly be nice to have the time-of-day shown in the viewer.  Most
|  of my photos (even scanned-in pics, thanks to APS info) have got both
|  date & time stamps that I trust.
I had that for a long time in the beginning, and threw it out at the end
because I found that I never used it at all. I doubt that you really would
use this for anything.

|  Hide the image information on the viewer:
|  I see a wishlist already for a time-out on that info, but other options include
|  semi-transparency of the information, or having it underneath the image in
|  a kind of 'status bar' etc.  With a few names and a description and date
|  and location field all populated, the black-box can hide a lot of the photo.
|  Perhaps even being able to nominate which fields are shown, the order
|  they're shown, maximum space to allocate for each, etc.  The filename
|  could even be inserted into the title of the window - sometimes there's
|  good info in the filename.
try pressing the letter i in the viewer that will toggle the box.

|  Export selected files:
|  In addition to the current wishlist to be able to 'copy all selected files to a
|  nominated directory' (how about a sub-dir created that contains symlinks
|  to all the selected files?), it'd be great to be able to dump a .txt file that
|  corresponds to each image, that contains all the Location, Persons, etc
|  information for each image.  An option to dump all that information into
|  a single .txt file (for people afraid of CLI's and cat ;( ).  This would be good
|  for when you're emailing a set of photos to non-kimdaba-enabled friends.
|  I know it'd be easier to acquire smarter friends, but this takes time.
I'm working together with digikam, showimg, and viewimg on a common plugin
structure, this will indeed be the job of such a plug in, please restate
your wish when that is implemented - and someone else but me could make
such a plugin.

|  Rename field:
|  Rather than find all files that match a keyword, selecting them all, creating
|  a new keyword, and then deleting the old one -- it'd be great to be able to
|  just rename a Person, Keyword or Location, and have all references to that
|  item changed across the entire database.
right click on the name in the listbox and choose rename, and the name will
be changed in the whole database.

|  Echoing earlier wishlists:
|  Please please .. let the ThumbNails be stored in a different directory.  It's
|  easy to get rid of them, but then it slows down the viewing process later.
|  Just being able to nominate a different directory would be enough -- it'd
|  still be fast to browse in kimdaba, and it'd keep my image directories
|  uncluttered.
well it just happens that I disagree on this one, sorry ;-)

Thanks for your input.


More information about the Kphotoalbum mailing list