PIM-Item Relations / Categories

Christian Mollekopf mollekopf at kolabsys.com
Wed Jun 6 11:54:56 CEST 2012


On Wednesday 06 June 2012 10.38:54 Thomas Brüderli wrote:
> Christian Mollekopf wrote:
> > Hey,
> > 
> > While going through color configurations for categories
> > (http://wiki.kolab.org/User:Greve/Drafts/KEP:12), I noticed once again how
> > broken/misused categories are (Think what renaming/moving a category does
> > to the stored color configuration).
> > 
> > That and slowly more pressing needs in Zanshin made me take another look
> > at
> > Pim-Item Relations.
> > 
> > Currently we have only categories to put PIM-Items in some structure,
> > which
> > are basically just plain-text tags, and not sufficient for what we're
> > trying to do.
> > 
> > I already explained the new concepts ("Projects", "Contexts" and
> > "Topics"),
> > which I'd like to use in my last mail to this list:
> > Fwd: [Kde-pim] Organizing calendaring items and notes
> > and now also in the wiki:
> > http://wiki.kolab.org/PIM-Item_Relations#Concepts
> 
> How does the INBOX concept of GTD fit into all that? Will it just be
> another context or more a specific resource/folder?
> 

Zanshin just creates a toplevel structure:
* INBOX
** Item1
** Item2
* Projects (respectively Contexts/Topics)
** Project1
*** Item3
*** Item4
*** Project2
**** Item5
Every item which doesn't have any Project/Context/Topic ends up in INBOX.

> > I plan to add the parent-relation construct (http://wiki.kolab.org/PIM-
> > Item_Relations#Parent_relation_tree) soon to KEP 17, and to remove the
> > hierarchical categories. As first user of this functionality, I'm going to
> > prepare Zanshin to read/write the relations in such way, the rest of
> > Kontact will remain untouched for now (It's mainly useful for todos and
> > notes which is the realm of zanshin).
> > 
> > Plan of action:
> > * Add PIM-Item Relations to KEP 17
> > * Use categories as plaintext tags only.
> > * Don't support category hierarchies.
> 
> I'd definitely vote for that but I remember this being mandatory because
> Kontact has hierarchical categories and somehow needed to map this into
> Kolab storage objects.
> 

Maybe we have to... Maybe categories can also indeed be useful for calendars, 
which I might have been ignoring too much...
In any case we shouldn't use categories as primary organization mechanism for 
todos and notes.

Cheers,
Christian

> ~Thomas
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://www.intevation.de/mailman/listinfo/kolab-format
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20120606/259b73ab/attachment.sig>


More information about the format mailing list