[Kde-pim] Re: Usage of standard akonadi collections/resources within different applications
Kevin Krammer
kevin.krammer at gmx.at
Fri Jan 7 18:31:59 GMT 2011
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?
> -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 :(
> 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.
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.
> 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.
> -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.
> 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.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110107/f0aece23/attachment.sig>
-------------- next part --------------
_______________________________________________
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/
More information about the kde-pim
mailing list