[Kde-pim] Re: Usage of standard akonadi collections/resources within different applications

Sat Jan 8 03:06:02 GMT 2011

On Friday 07 January 2011 19:31:59 Kevin Krammer wrote:
> Hi Chris,
> 
> On Thursday, 2011-01-06, Christian Mollekopf wrote:
> > Hi,
> > 
> > I have some questions regarding the usage of the collections which are
> > configured in the KDE Resources dialog in the systemsettings. (sorry for
> > the lengthy mail)
> 
> The KDE Resource dialog is more or less only here for legacy reasons, might
> be removed once all apps have transitioned to native Akonadi usage.
> 
> > Background:
> > I'm working on an app which mixes notes and incidences (todos and
> > events).
> > 
> > You can find a short description and a screenshot here:
> > http://gitorious.org/notetaker/pages/Home
> > 
> > While i keep notes and incidences in different collections, I use for
> > incidences the same collection as in KOrganizer, so I have a timebased
> > view in kcalendar, and a listbased view in my app.
> > For notes I use the same resource type as kjots (akonotes), but I don't
> > have a hierarchy with collections (as kjots), since I build the hierarchy
> > using nepomuk relations. Instead I store all notes directly in the
> > toplevel notes collection, plus I have a trash collection, where I move
> > deleted notes and also incidences.
> > 
> > Current Collection Layout:
> > 
> > -KCalResource  <- Incidences
> 
> Meaning you are using the KResource interface for KCal? I.e. KRES::Manager
> KCal::Resource?

Sorry, that was a bit misleading. I'm using the same collection as I have 
configured in korganizer. The collection is owned by a resource of the type 
akonadi_kcal_resource.
> 
> > -NotesResource <- Notes
> > 
> > 	-Trash <- Notes and Incidences
> > 
> > Questions:
> > For the Calendar collection there shouldn't be a problem. I can just use
> > the default collection which is configured in the system settings by
> > default, and offer a gui to select another collection (Is the one from
> > korganizer reusable? I couldn't find it).
> 
> I don't think there is currently a system wide concept of a default
> calendar collection. Could be KOrganizer internal. Sergio?
> 
> As for collection selection, there are several options:
> - Akonadi::CollectionDialog
> - Akonadi::CollectionComboBox
> - using a collection or entity tree model with a view of your choice.
> 
> > Korganizer doesn't show newly added todos/events while it's running, but
> > it works if i restart it. So if there isn't a conceptual problem with
> > two applications using the same collection, I will just look into
> > korganizer later on.
> 
> That should work but the KResource plugin for calendar is crude and the
> KOrganizer with native Akonadi support hasn't been released yet.
> Nothing you could really do something about right now, sorry :(

No problem, that was to be expected. But in this case there are definitive 
plans to fix this, so korganizer will react properly to external changes in the 
future (excellent!).
> 
> > Trash Collection:
> > The trashcollection is currently a subcollection of the notes collection.
> > I move atm. both notes and incidences to the trash, which is a bit of a
> > hack, since it it supposed to be a notes only resource (I assume that
> > would also cause problems once there is an agent for i.e synchronizing
> > notes or feeding them into nepomuk).
> > 
> > I think I have two options:
> > 
> > -Create a toplevel trashcollection (for notes and incidences):
> > 	Probably the easiest, but the items would not be synchronized by a sync
> > 
> > agent
> > -Create a trashcollection in the notes collection and the kcalendar
> > 
> > collection:
> > 	While this works with kjots, I don't know how kcalendar would react to a
> > 
> > new subcollection (whose content should be hidden)
> 
> A trash's content is still valid, i.e. should probably be accessible
> through a user interface anyway (file trash and mail trash are, for
> example). So I wouldn't worry about it showing up somewhere else.
> 
Yes, the content is still valid, but it shouldn't be visible to the user 
anymore, unless he decides to visit the trashbin (e.g. because something was 
deleted by accident). This means, if I delete an event in my app, it should 
also be gone from korganizer.

The best solution IMO would be if there was a trashcollection in every 
resource (at least in the notes and the incidences resource).
This would make sure that if e.g. korganizer would also use a trashbin instead 
of deleting incidences directly, the handling between the two applications 
would be consistent (i.e. trashbin shows the same items).
It would also enable the resource to handle things like syncing also the 
trashitems to somwhere else, or autodeleting old items (don't know if that 
would be reasonable for a resource agent to do). 

While it would be better to have a more generic solution, I think the easiest 
way to go for now is to use another rootcollection (without any resource 
agent), where i move deleted notes and incidences. I can then e.g. 
periodically delete items which are older than e.g. 2 weeks or so and offer an 
interface to restore the items.

If there is a general interest though, to make a more generic solution, I 
would be happy to work on it.

> As for use by other agents/clients, I would say that this is a matter of
> these clients' configuration, i.e. they should probably provide an
> interface to select collections to work on, not assume they can always
> autodetect what any user will want to do.
> 
> > Is there a general concept for trashcollections?
> 
> No, right now trash is only used in the context of email and there it is
> basically just a special attribute of a collection, since each resource
> could have its own trash collection.
I assume that attribute is puerly kmail internal and not a standard which will 
eventually be understood by other applications?
> 
> > Notes collection/resource:
> > -The current systemconfiguration offers the possibility to configure a
> > "Note" resource, but instead of an akonotes resource a fileresource for
> > knotes. Will that eventually be replaced by an akonotes resource?
> 
> My guess is that this will replaced in such a way. Haven't really looked
> into notes and related things at all, others might have better input here.

I assume, since you say that the KDE Resources are a legacy thing, this 
configuration will be removed eventually anyway. So I'll just provide my own 
interface to select and create the needed collections, just as korganizer 
does.
> 
> > -If the central configuration is changed to akonotes, I could just use
> > the "standard" resource per default. But since kjots might use the same
> > resource, I don't know if this is the way to go since kjots would end up
> > with all notes created in my app directly in the notes collection (not
> > in "books" aka subcollections).
> 
> You could probably create your own instance of such a resource and offer
> the one most likely used by KJots as well or detect the existance of an
> instance at first start up and offer using it instead of creating your
> own.
> 
> You could also create your own resource type and its collections (due to
> properly reporting MIME types) would still be accessible in applications
> that can handle these MIME types as well, e.g. your calendar collection
> showing up in KOrganizer.

Yes, but I don't see any drawbacks in using the existing resource type and 
just storing notes and incidences in the two different collections(with two 
different resources), instead of creating a new resource which combines notes 
and incidences.

> 
> > So, I think I need to know how the central configuration for KDE
> > Resources is intendet to be used, or if I have to create a configuration
> > interface myself (which I'd like to avoid).
> 
> I recommend avoiding KDE Resoures, they are on their way out.
> 
> As for configuration of standard calendar/notes collections I'll have to
> defer to the guys working on apps in these areas.

Thanks a lot for your comments,

Chris
> 
> Cheers,
> Kevin
_______________________________________________
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/