[KimDaBa] Just-after-initial thoughts

[jedd]

On Thu February 26 2004 06:43 pm, you wrote:
 ] |  files?  Or is it a safety feature so you don't accidentally modify more
 ] |  files than you think you are?
 ] Please see

 Cool .. that makes sense now.

 ] I'm not sure I understand the question, when you say subset of .. would
 ] this help you:
 ] http://ktown.kde.org/kimdaba/kimdaba-doc/en/doc-multi-page/chp-typingIn.html#sect-specifying-properties-for-images

 Member groups are good for some things, but can't guarantee that
 every image will be represented in the parent group.  That is, you
 have to manually ensure that sydney, brisbane, melbourne, hobart,
 are all part of the australia group -- and when you add a new city
 group, you have to remember to add it into the parent group.  With
 small data this is easy, but there's no way to force you do this.  A
 hack like saying 'this is a country, and these locations aren't, so make
 sure they get assigned to a country member group' might work, but
 it'd be truly ugly and awful to manage.  I don't know of a good solution.

 There's also the problem of having very very long keyword lists, and
 wanting to separate them.  I'm creating extra option groups like 'Art'
 and keep things separate that way, which solves the 'everything must
 be a member' problem.

 I think this approach will work for me, I was just wondering what other
 people did (I presume they stick with member groups).  I suspect I have
 a significant number of quite varied parent groups that have lots of
 sub-groups themselves -- 'arty', pics of friends, of holidays, nature,
 recording where I've run several kilometres of irrigation pipes, etc.

 ] 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.

 Fairy nuff.  For the moment I'm adding one or two sub-directories at a
 time, which is (once I catch up) exactly how I'll maintain the database
 day to day anyway, and it's slow but live-able.

 ] drag off the window with the thumbnail view, and resize it. Seems like I
 ] have a candidate for a FAQ here ;-)

 Ahh, perfect.  And yes, that FAQ's getting plump now.

 ] Select a bunch, and press Ctrl-1 (see URL above)

 I'm feeling very enlightened today.

 ] 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 ;-)

 The odd thing is that when the window pops up, it looks like there's
 the vertical bar ( | ) cursor in the Persons text box, but only for a second,
 and then it's gone.  It's almost like it's teasing me.

 Tab-sequence in lots of kde apps seems somewhat random, I've noticed,
 so I've always assumed it to be a weakness of the Qt libraries.  But is
 initial focus similarly borked with Qt?

 ] Added remember windows size to TODO.
 ] Regarding the image config window, choose Options -> Save current window
 ] setup
 ] http://ktown.kde.org/kimdaba/kimdaba-doc/en/doc-multi-page/sect-changing-layout-of-the-property-window.html

 Yup, I've played with that already, and discovered a bug .. of sorts.

 I have a large options dialog, with persons/location/keyword contained in
 it, and then a separate window with 'subject' in it.  When I save the current
 window settings, what seems to happen after I stop and then start kimdaba
 is that the persons/location/keyword window reverts to being tiny (normal
 size) and the extra 'subject' dialog is the same size as the main window was
 when I saved the settings.  (Does that make sense?)

 It looks like it's saving the wrong window's size.  I'm guessing you don't
 use extra option groups much on your own image database?

 ] |  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
 <snip>
 ] It is indeed keept, I think understanding Ctrl+1 above will help you if
 ] not, please tell me what you do.

 Hmm, highlight is kind of there actually.  When an image is selected, it
 has a greyed look.  When I change its properties, and come back to the
 thumbnail view, it's changed back to normal colours.  However, if I 
 click on an empty part of the thumbnail view, then the name of the image
 then gets highlighted with a dotted-line around it.  What I think would be
 nicer is if the image remains greyed, though.  I'll play with it some more,
 given your suggestions about multiple-selects and ctrl-1 .. and see if it
 still makes sense to me to maintain the highlight.

 ] Try Ctrl+T (Help -> show tool tip on images)

 Ahh .. {even more enlightened look}.  Nice.

 ] 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.

 Remove the /*'s and add a setting in the Configure box?  ;)   I tend to agree
 that it's not *hugely* useful, but I like the idea mostly for completeness.
 (Plus I spent lots of time making sure my time-stamps are correct!)

 ] try pressing the letter i in the viewer that will toggle the box.

 You know, I'm normally much better about reading documentation.  Sorry.

 ] well it just happens that I disagree on this one, sorry ;-)

 I *really* hate static ThumbNails in almost any app.  Even web frontends
 rarely need them much anymore, given there's usually enough power to create
 various sized images dynamically.

 But specifically with kimdaba -- I've changed the thumbnail size a couple
 of times (small when browsing, large when setting multiple files' keywords),
 and so I now have more than twice as many thumbnails as images :

~/private/pictures/MinoltaPics$ du -a | grep  ThumbNails | wc -l
3429
~/private/pictures/MinoltaPics$ du -a | grep  -v ThumbNails | wc -l
1552

 Not so bad with reiserfs, where running out of inodes and sub-blocksize files
 aren't so much of a problem, but it's still a significant amount of space, some
 of which will never be used now I've changed the thumbnail size again :

 ~/private/pictures/MinoltaPics$ du -sch */*/ThumbNails
 31M     total

 And those figures are against roughly half of my total pics so far.

 Anyway, there's plenty of time to argue about thumbnails later.  ;)

 Thanks again for your help,
 Jedd.