[Kde-pim] Handling Virtual Collections/Resources in Akonadi applications

[Stephen Kelly]

Tobias Koenig wrote:

> On Wed, Aug 12, 2009 at 01:27:54PM +0100, Stephen Kelly wrote:
>> Hi,
> Hej,

<snip>
 
>> The virtual resource could then be removed with another action, or
>> whatever the Thomases decide.
>> 
>> Most of the work on this will be done by me anyway, but I'd like to get
>> good idea/bad idea concensus. Any thoughts on that?
> Hmm, we need an identifier for this for sure, but maybe we can add another
> parameter
> 
> enum Visibility
> {
>   Global,       ///< Search collection is visible for all application.
>   Application,  ///< Search collection is only visible to application with
>   the given identifier.
> };
> 
> So the SearchCreateJob would have the following ctor
> 
>   SearchCreateJob(const QString &name, const QString &query, Visibility
>   visibility, const QString &identifier);
> 
> The created search collection would contain a special
> SearchVisibilityAttribute that contains the Visibility flag and the
> identifier.

Yes, an attribute would be a nice way to tell the ETM that it should show multiple virtual collections which should have more visibility.

> 
> The ETM would provide a method 'setSearchSession(const QString&)' where
> the identifier of the application is passed that uses this instance of ETM
> (e.g. kmail would pass 'kmail' ;)). Now the ETM could query all search
> collection and evaluate their SearchVisibilityAttribute. If the Visibility
> is set to Global, it is always included, if Visibility is set to
> Application, the collection is only included if the identifiers match.
> 
> Comments?

Instead of inventing a new search session string, you could instead use the identifier of the Akonadi::Session you passed into ETM. ETM already knows that, and your application should too if it's kept around as m_sesssion or something.

However, can you think of any use case for that? Would anyone actually run both KMail and Mailody and show the same search collections in both? Can you think of a contact-type use case? Isn't it dangerous to set global visibility on a virtual collection like that? The ETM in kaddressbook could obediently show a virtual collection of contacts which don't have a particular role being in KAddressBook. For example, if you have a plasmoid showing people who enjoy 'giraffes', and the plasmoid author decided to set global visibility on it, not knowing what the flag does.

KAddressBook would also obediently try to process a virtual collection containing emails that someone sets global visibility on. Of course, the SearchVisibilityAttribute could store a mimetype too for filtering, but then I'm again stuck on the use case part.

All the best,

Steve.

> 
> Ciao,
> Tobias


_______________________________________________
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/