Arnd,

It's certainly a duplicate from B.K.O... A lots of reports about this subject have been already done in the past.

Gilles

Nadav,

>(i'm a little confused with all the metadata fields names in >EXIF/JPEG/IPTC/JFIF/DIGIKAM's DB...)

Are you read the digiKam handbook ???

http://docs.kde.org/development/en/extragear-graphics/digikam/using-sidebar.html#using-sidebarmetadata

Gilles

Hmm, it seems that "Image caption" finds words given in the comment of
the image?
But also searching for "Keywords" works in the example I have set up
(Comment field of one image contains "blurb" and searching for "blurb").
Do you have an example where "keywords" and "Image caption"
given different results?

Gilles, what is the difference between "Image caption" and "Keywords"
in the advanced search?
Should "Image caption" be renamed to "Image comment" ?

The only slightly related bug under searches seems to be http://bugs.kde.org/show_bug.cgi?id=139283

Arnd,

Image Caption == image comment

In fact, "Caption" can be renamed as "Comments", if English term is fine to use. If yes, well the same change must be done with "Album Caption"

about "Keywords", well i'm not sure. I need to check source code.

Gilles

when i edit the image's description it says "comments" on the right side tab.
are they JFIF/JPEG/EXIF/DIGIKAM's ? what does comments relate to ?

Am Thursday 27 September 2007 schrieb Gilles Caulier:
[bugs.kde.org quoted mail]

Gilles, i think there is a big usability issue here, I understand that users 
are confused. In particular there's no consistency between the search 
vocabulary and the sidebars. We need to review this in detail.

For now I strongly suggest to use "caption" instead of comment. Caption 
means 'title', 'story', 'explanation', 'comment', 'that what captures 
interest' and more. It is the much more appropriate label. :-)

If you agree I change the labels in both svn.

my 5cents
Gerhard

Fully agree, consistency is very important here.

"Caption" instead of "comment" sounds also more consistent with
Iptc.Application2.Caption
(though less with Exif.Photo.UserComment)

In addition, is there a way to provide information (on a mouse over)
on the meaning of each field which can be searched for
in the advanced search?
(I.e. to avoid that normal users have to look up the code
about the meaning ;-)

To Gerhard,

I'm agree of course, let's go...

To Arnd,

On mouse over help is Qt ToolTips. It's really easy to code. Note that Qt provide also another way name WhatsThis. What the difference ? Tooltip is a small description of widget instead WhatsThis is a complete one.

ToolTip appears over a widget by a mouve over event.
WhatsThis appears when user use SHIFT+F1 or Help/Whats This option.

In Qt3 code is like this :

    d->saveTagsIptcBox = new QCheckBox(IptcGroup);
    d->saveTagsIptcBox->setText(i18n("&Save image tags as \"Keywords\" tag"));
    QToolTip::add( d->saveTagsIptcBox, i18n("Small descrition here"));
    QWhatsThis::add( d->saveTagsIptcBox, i18n("Full descrition here"));

In Qt4 code is like this :

    d->saveTagsIptcBox = new QCheckBox(IptcGroup);
    d->saveTagsIptcBox->setText(i18n("&Save image tags as \"Keywords\" tag"));
    d->saveTagsIptcBox->setTooltip( i18n("Small descrition here") );
    d->saveTagsIptcBox->setWhatsThis( i18n("Full descrition here") );
                                           
I try to provide at least a ToolTip everywhere on GUI and WhatsThis where user need more advanced informations. Generally, WhatsThis content is a duplicate of handbook.

Gilles

In searchwidgets.cpp one has
    m_key = new QComboBox( m_hbox, "key" );
    m_key->setSizePolicy( QSizePolicy::Fixed, QSizePolicy::Minimum );
    for (int i=0; i< RuleKeyTableCount; i++)
        m_key->insertItem( i18n(RuleKeyTable[i].keyText), i );

Of course it is no problem to add another description field
(e.g. `keyToolTip`) to the RuleKeyTable struct.
In the loop, would something like
       QToolTip::add( m_key->currentItem(),
                              i18n(RuleKeyTable[i].keyToolTip));
work on the entries of such a QComboBox?
(TheQComboBox Class Reference does not mention anything in this respect)

Looking at the contents
    { I18N_NOOP("Album"),            "album",
    { I18N_NOOP("Album Name"),       "albumname",
    { I18N_NOOP("Album Caption"),    "albumcaption",
    { I18N_NOOP("Album Collection"), "albumcollection"
    { I18N_NOOP("Tag"),              "tag",
    { I18N_NOOP("Tag Name"),         "tagname",
    { I18N_NOOP("Image Name"),       "imagename",
    { I18N_NOOP("Image Date"),       "imagedate",
    { I18N_NOOP("Image Caption"),    "imagecaption",
    { I18N_NOOP("Keyword"),          "keyword",
    { I18N_NOOP("Rating"),           "rating",

I think that only "Tag" vs. "Tag Name"
and "Image Caption" vs./and "Keyword" would require an explanation
(BTW: is the "Album collection" stuff gone in KDE4?).

Arnd,

>work on the entries of such a QComboBox?
>(TheQComboBox Class Reference does not mention anything in this respect) 

QComboBox is derivate from QWidget. We can associate a QToolTip/QWhatThis to all QWidget class, and of course this include all childrens class derivated from QWidget (C++)

>BTW: is the "Album collection" stuff gone in KDE4?

it already present in KDE3 code. Look Setup Collection page.

Gilles

This is the zoo of image "captions/comments":

JFIF comment
EXIF user comment

Iptc Caption/Abstract
Dublin Core/Photoshop Description

Iptc/Photoshop Headline

Dublin Core/Photoshop Title
Iptc Object Name

Nadav,

Following recents progress into new Advanced Search tools from Marcel with KDE4 port, i close this file.

Search tools have been rewritten. Screenshots are available at this url:

http://digikam3rdparty.free.fr/Screenshots/NewSearchTools

Gilles Caulier

Gilles,
thanks :-)

i looked at the pictures, woo o ww  w  !

i am still using digikam with kde 3.5.x but i am looking forward 
into moving into kde4 some time soon :-)

Nadav,

digiKam 0.10.0 will run with KDE3 desktop. We use only KDE4 shared libraries. No need to run whole KDE4 desktop (:=)))

Unlike you can read around KDE world over the web (dot.kde.org for Ex.) KDE4 desktop is not yet stable (This is my viewpoint as developper). This is why i have not planed to publish digiKam 0.10.0 just for KDE4.0.0. With my experience as developper and my work in open-source, I feel than KDE4 will be really suitable for 4.1 or 4.2 release. For Ex, i'm not sure than all printing capabilities will be restored for 4.1. Who will work with a desktop without printing options ???

Gilles