Bug 142566

In fact, it seems the old date is cached so I can't see the change :
1. I select a photo
2. I change the date
3. I select another photo and next, the first one
==> The old date is displayed in the Comments/Tag panel
4. I move to another album and I go bak to the previous album
==> The date has changed

See also my comment at bug 141601, comment 2.
I think bug 141601 is the same issue.

Fred,

This problem still reproductible with 0.9.2 ?

If you can, try also digiKAm 0.9.3-svn...

Thanks in advance

Gilles Caulier

I can reproduce the problem with 0.9.2.
The problem exists for Date but not for tags : If I check a tag and if I select another photo, the tag is correctly displayed on the previous photo.
I'll try with digiKAm 0.9.3-svn

I can confirm the problem as described in #1 above
with current svn.

Sounds a bit a like a signal is not emitted?

Yes, Arnd, or a chache problem. Marcel ?

Gilles

I had a quick look: in magedescedittab.cpp, the d->dateTimeEdit
is connected with 

void ImageDescEditTab::slotDateTimeChanged(const QDateTime& dateTime)
{
    d->hub.setDateTime(dateTime);
    setMetadataWidgetStatus(d->hub.dateTimeStatus(), d->dateTimeEdit);
    slotModified();
}

So to my naive eye this looks ok. 
However I am wondering, whether an additional explicit call to 
  void ImageDescEditTab::updateDate()
would be necessary?

*** Bug 145723 has been marked as a duplicate of this bug. ***

What's news for this report. It still valid using digiKam 0.9.4 ?

Gilles Caulier

This is still valid with current 0.9.5svn:

1. Change date in Comments panel, click Apply
2. Go to another image and return
3. Date still the same
4. Date only updated after changing to another album and returning

When not clicking Apply I am asked for confirmation date is updated.

I think this is fixed with 0.10.0 beta 7.

Marcel,

I confirm this bug for 0.9.5. I cannot see why it doesn't work. ImageDescEditTab::slotApplyAllChanges() call properly MetadataHub::write() which change date of imageinfo relevant using ImageInfo::setDateTime(). This one dispatch changes using ImageAttributesWatch::imageDateChanged() and AlbumIconView::slotImageAttributesChanged() recieve notification about date changes. In this case, AlbumIconView::updateContents() is called, but date do not change in icon view...

Note : why we have this code here :

void ImageInfo::setCaption(const QString& caption)
{
    AlbumDB* db  = m_man->albumDB();
    return db->setItemCaption(m_ID, caption);
    ImageAttributesWatch::instance()->imageCaptionChanged(m_ID);
}

The return instance sound weird...

For 0.10.0, i confirm: this bug is fixed. Creation date is fixed imediatly in icon view.

Gilles

Yes it really seems the "return" should be removed there. Maybe it works afterwards?

I am seeing a related bug where when viewing by date in the calendar, changes to date do not take effect. Pressing apply doesn't help. I have to change views, ie: by tag, and then I can change the date and it takes effect.

Digikam 0.9.4
Debian Lenny

To Marcel #13 : fixed with rev; #898821

Gilles

Marcel,

What do you think about this file ?

As it's fixed with 0.10.0, do you want to close it as fixed with KDE4 or do you want to fix KDE3 version too ?

Gilles Caulier

Not sure, currently I prefer to fix bugs for 0.10, and this bug is for KDE3 only. May be a lot of work to debug.

Marcel,

Note : as Thomas said in comment #11, it's sound fixed for KDE4...

Gilles

I guess we should close it now? :D

Andi

If Marcel is agree, fine for me. We will not play with KDE3 code now (:=)))...

Gilles

I've done so today, and it was not nice :D
I have missed cmake after the first two seconds... SO MUCH nicer!

This file is fixed in KDE4 code. I close it.

Gilles