[Nepomuk] [Kde-pim] Notes in KDE in the future

[Laura Dragan]

Stephen Kelly wrote:
> 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.

Great idea, thanks for sharing. I've been following the discussion on
plasma-devel and was thinking that a meeting on irc might help to get to
a decision faster ..

>
> 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.

This is a nice-to-have thing I would like to add to semnotes but later
on, so a nice API would really help :)

>
> 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.

Currently I store the notes in the Nepomuk store together with all the
information about them. What I had in mind for Akonadi integration was a
sort of note resource that would synchronize the notes from nepomuk with
akonadi. I did not go further into it, as to decide if i should create a
new collection for these notes or they should be added to an existing
collection of notes, or how to store the relations i have for notes to
other nepomuk things like people, projects, etc. Storing these relations
between objects is what nepomuk is for, and i'm not convinced that it
makes sense to duplicate them in akonadi. It would be nice however to
have a nepomuk feeder that moves the notes from akonadi to nepomuk, so
that notes written in kjots / knotes / basket can be shown in semnotes.

You seem to have the storage in akonadi figured out - or almost .. so we
should think of a consistent way of storing them in nepomuk, and then
make the akonadi resource/feeder follow the formats we agree on. This
way, no matter where the notes are - files, akonadi, nepomuk - they
should be accessible and synchronized.

I plan to discuss the way i store the notes in semnotes at the nepomuk
meeting next weekend and hopefully get to a stable version, regarding
which classes/properties are best to use. So far I had not taken into
account other mime types than text, so this will be on the todo list as
well.


Laura


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