[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] timestamps
From:       Anders Lund <temp_and () tiscali ! dk>
Date:       2002-09-29 21:57:08
[Download RAW message or body]

On Søndag den 29. september 2002 16:32, Reinhold Kainhofer wrote:
> Am Sonntag, 29. September 2002 13:54 schrieb Tobias Koenig:
> > The interface isn't broken, but the behaviour changed.
> > Normally only Addressees in a KABC::AddressBook are saved by the
> > resources, when the Addressees are marked as 'changed' (use
> > Addressee::setChanged(bool) for it). Until now they are marked as changed
> > automatically in the method AddressBook::insertAddressee( const Addressee
> > &addr )
> > when addr is already included in the addressbook (in other words: if
> > there is already a Addressee with the same uid), but differs from the
> > included one.
> > Since the undo/redo stuff in kaddressbook insert and remove the Addresses
> > in a ugly way, they get marked as changed, even if that's not the case.
>
> Then that's a kaddressbook bug and should be resolved there, isn't it?
> Actually I would prefer to keep the current way to automatically flag
> changed items, but add a function to also set/unset it manually, when you
> know you have to.
> After all, the rationale behind libkabc is to make it simple for
> applications to work with addressbooks, not to require several lines of
> code just to update one addressee. Eventually one will forget at least one
> of the steps in the code, and then trying to find the bug is really not
> much fun.

Agreed. If the bug is due to KAddressBook handling changes by 
removing/reinserting, that is bad. I think kaddressbook needs a lot of 
cleaning to that side, it also updates it's views by clearing/readding all 
items, which is waste of time - apart from the aestethical ugliness;)

> > Furthermore the central setRevision() sets the revision for all changed
> > Addressees to the same timestamp.
>
> What's so bad about this? They are saved simultaneously, so this can be
> justified. Why don't you set the revision to the time you actually change
> it?

The timestamp should reflect when an addressee was last changed. period.

-anders
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]