[Kde-pim] synchronizing a collection

[Sebastian Kügler]

Hi Stephen,

On Tuesday 14 April 2009 06:02:46 Stephen Kelly wrote:
> Sebastian Kأ�gler wrote:
> > I'm trying to write the implementation for a refresh button in Lion Mail
> > collections. I'm running into two problems, though;
> >
> > - Akonadi::Collection(id).resource() returns an empty string
>
> This is because Akonadi::Collection(id) doesn't come from the server, so it
> doesn't know its resource. Agent manager knows all the resources in Akonadi
> though as you noticed. It caches those for convenience. You would need to
> do something like
>
> Collection wantedCol = Akonadi::Collection(id);
> Job *job = new CollectionFetchJob(wantedCol, BaseCollection);
>
> and get the collection out of the result of the job.

I'll try that, thanks.

> That's just FYI. You don't really want to do that. You don't need a refresh
> button at all. Instead, you should be using a Monitor on the selected
> resource and reacting to it's itemLinked and unlinked signals.

Synchronizing and those signals are quite different actually. I'm workin with 
those signals already and that seems to work. The synchronize button is there 
to synch the cache of the collection in Akonadi with the original copy on the 
IMAP server (for example). So the refresh and itemadded stuff complements each 
other.

> Presumably when lion mail is finished, that will be a virtual resource of
> some kind and linking a new item means a new mail has arrived and should be
> shown. I think lionmail should not react to itemunlinked though. When the
> user reads a new email, you should be starting a itemModifed job with the
> 'unread' flag removed, so that other applications can react to it being
> read. That would cause an itemunlinked signal to come through your monitor
> which, if lionmail reacted to it, would make it impossible to read mail. I
> guess you should clean up mails that have been read periodically, and maybe
> provide a i18n('Clears emails that have been read from the email list',
> 'Clear read emails' ) action.

Agree. Deleting emails from the UI istantly is a bad idea. Two thoughts on 
that:

 - Lion Mail primarily does "glancing" at emails, not so much really reading    
   it. Not sure wether that qualifies to mark emails as read automatically 
   when they've been glanced at.

 - If we're to remove emails from the UI automatically, yes, there shoud be 
   some kind of mechanism so it does remove emails from the user's view he 
   might still be interested in (like purge, or a timeout, or ... something).

> If lionmail should also be able to display mails from any arbitrary
> collection, I guess you'd have to implement slots for
> item{Moved,Removed,Added} too. You also need to implement a slot for
> itemChanged either way.

What do you mean by arbitrary collections? I think I'm already doing exactly 
that (i.e. you can choose to show any (email)collection you like).

> > Can someone enlighten me? :)
>
> HTH.

A bit :-)

Thanks,
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/