[Kde-pim] Notes in KDE in the future

[Stephen Kelly]

Hi,

Following from the thread we had last week about notes I'd like to thrash 
out a few ideas and see if we can get some agreement/consensus about how to 
serialize the data, how to share notes between different applications, how 
nepomuk fits in, and what the user experience should be. Unfortunately I 
won't be going to the Nepomuk meeting, but as it's coming up soon I thought 
I'd get the ideas out as are currently in my head at least.

KJots currently stores top-level books in an xml format. The entire 
heirarchy below a top level book including its child books is stored in one 
file. The data is pretty much always converted to html, not giving the user 
a chance to make a note plain text only. On the other side, it is not 
currently possible to store images and other media like sounds for example 
in kjots notes.

As a starting point for allowing such things, I've started to convert kjots 
in the akonadi ports branch to use mime messages as notes. This has several 
advantages especially relating to akonadi, because we already have the kmime 
library for handling mime messages, akonadi has a serializer for mime 
messages, having different messages of different mimetypes is normal in 
mime, eg text/plain, text/html, and multipart/related for text with media. 

There are also several good storage solutions for mime messages, like 
maildir for example which allows storage of a heirarchy of notes. We already 
have a maildir resource in akonadi, so it was possible to subclass that and 
use it for notes too. All I had to do in the subclass was make it use a 
different mimetype, text/x-vnd.akonadi.note to differentiate from a resource 
holding actual mails. Volker already made it possible to store the notes on 
a kolab folder too.

For the above re-use of existing akonadi code I think it would be a good 
idea to use mime structures for notes. For applications, this means dealing 
with KMime::Message::Ptrs, which are boost::shared_ptrs instead of whatever 
notes class was used before. This is not very convenient, so it might be 
possible to make some more convenient API for handling notes which doesn't 
need all the complex stuff in kmime. The applications of course don't care 
if the notes are in maildirs or on kolab if they just retrieve them from 
akonadi.

For applications using akonadi, I think a challenging aspect is dealing with 
notifications coming from akonadi in a sane way. Akonadi could notify at any 
time that a new note has been inserted by another application into a notes 
collection and must be shown in your application too. This has been causing 
some discussion in the attempt to put notes from akonadi into the plasma 
workspace, because there are several ways to do it, none of which cover 
everything we want to do.

My current idea is to put notified new notes into a extender and have one 
master applet with each note as a plasma extender item.

Unfortunately the gmane view onto plasma-devel@ is broken, but you can see 
it here:

http://markmail.org/search/?q=how%20to%20get%20akonadi%20notes%20into%20plasma#query:how%20to%20get%20akonadi%20notes%20into%20plasma+page:1+mid:uvsxfwpgqpor74iy+state:results

http://officespace.kdab.net/~stephen/notes_plasma.ogv

One of the nice things about that is that a particular plasma activity could 
show a particular collection of notes, including only notes annotated in a 
particular way by nepomuk. So you could have your "organizing the football 
team" plasma activity show the notes associated with the task or project 
"organizing the football team". Sebastian Trueg has mentioned before that 
simple tags shouldn't be used here, because tags are "stupid static 
strings", and something like tasks can have more meaning in nepomuk. 

There was an idea of allowing any search folder to be used in plasma for 
example, but I don't think that would make sense. For example if you were 
showing notes containing the work "giraffe" and you create new note in 
plasma, you expect it to show up on the workspace. We can't just put the 
word giraffe in there to make that happen, so I think we should try to 
restrict notes apps to associating notes with tasks or whatever ontology is 
deemed best. 

Then if a new note is created while showing notes in the "Organizing the 
football team" notes collection, it automatically gets associated with that 
task. That would mean that each of the notes apps would need some user 
interfaces for associating notes with tasks. Another difficulty that arises 
is that notes created in that way would have to exist in some concrete notes 
collection before they could be put into a virtual collection of notes for a 
particular task. One option would be to put them into a "Unsorted" notes 
collection in a local notes resource.

Another aspect of notes which I think needs to come into all of the 
applications is more semantic annotation of the content of the notes, which 
is what semnotes already does. That is orthogonal to the rest of the stuff I 
wrote about, but it is something else for the application developer to have 
to implement support for.

What do you think of all this? I realize that sharing data between the 
different notes solutions is a lot harder than each one rolling their own, 
and it could impose some restrictions on the applications, but it will 
hopefully make and could give nice user interaction and choice/swapping 
between applications.

All the best,

Steve.



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