[Kde-pim] Notes in KDE in the future

Mon Nov 2 15:06:36 GMT 2009

Dr. Robert Marmorstein wrote:

> I forwarded this message to basket-devel.  It sounds like a good way to
> possibly standardize the "note" format so that different interfaces can
> share
> them.  Of course, in BasKet, notes are pretty fancy, so it's especially
> difficult to serialize them.

Yes, I see there's a lot of cool stuff in there. Things like ratings, 
progress, priority, work/personal annotations, custom states and tags. Those 
things could likely be stored in nepomuk though, not serialized to the note 
itself and stored in akonadi.

> 
> In fact, this is the biggest barrier to Akonadi integration right now:
> factoring out the data about notes that is spread out over dozens and
> dozens of C++ classes.

Yes, such a port is definitely not trivial. I wouldn't want to try to guess 
a timeline for any of this stuff.

> 
> While using KMime is a good foundation for sharing notes between
> applications, there are going to be a lot more implementation details that
> we need to work
> out.  It would be good if we could set up a more formal structure for
> joint standardization of a common "notes" format.

I agree completely. That is also part of the convenience api that I had in 
mind. KMime allows all manner of headers and structures that are relevant to 
emails, but not to notes. For notes we probably need only the title, the 
content, and maybe some details about the appearance, the date 
created/modified, what application created it, and what type it is etc.

Potentially, that could mean notes look like this:

Subject: The title of my note
From: Kjots4.4 at kde.org
Date: Mon, 2 Nov 2009 08:30:17 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

This is the content of my note.

== or ==

Subject: The title of my rich text note
From: Kjots4.4 at kde.org
Date: Mon, 2 Nov 2009 08:30:17 -0500
Mime-Version: 1.0
Content-Type: text/html;

<html> ...
This is the rich text content of my note.
</html>

== or ==

Subject: The title of my rich text with embedded media note
From: Kjots4.4 at kde.org
Date: Mon, 2 Nov 2009 08:30:17 -0500
Mime-Version: 1.0
Content-Type: multipart/related; boundary=content-boundary; type="text/html" 
start="main-content"

--content-boundary
Content-Type: text/html
Content-ID: main-content

A <b>rich text</b> note with an embedded image: <img src="cid:image1" />, 
and embedded sound: <audio id="audio" src="audio1" class="shadow" 
controls></audio>

This note should also work as expected in konqueror.

--content-boundary
Content-Type: image/png
Content-ID: image1

T2xkIE1hY0RvbmFsZCBoYWQgYSBmYXJtCkUgSS
BFIEkgTwpBbmQgb24gaGlzIGZhcm0gaGUgaGFk
IHNvbWUgZHVja3MKRSBJIEUgSSBPCldpdGggYS
BxdWFjayBxdWFjayBoZXJlLAphIHF1YWNrIHF1
YWNrIHRoZXJlLApldmVyeSB3aGVyZSBhIHF1YW
NrIHF1YWNrCkUgSSBFIEkgTwo=

--content-boundary
Content-Type: application/ogg
Content-Id: audio1

a3MKRSBJIEUgSSBPCldpdGggYS
BxdWFjayBxdWFjayBoZXJlLAphIH=

--content-boundary

I don't know if that would satisfy the needs of basket? We'd probably need 
to explicitly agree to what features should all of the applications support, 
and whether an application can write other information to the headers which 
the others can ignore, but must write out again when saving the note. That's 
the kind of thing that is already possible with KMime I believe.

> 
> From my perspective, it would be nice if we could also keep things
> compatible with kpilot's notes conduit....

Yes, that would be nice too. We need some lowest common denominator feature 
wise though. I'm not sure what format kpilot notes are expected to be in.

All the best,

Steve.

> 
> Robert
> 
> On Monday 02 November 2009 7:28:33 am 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.
>> 
>> 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%20pla
>> 
sma#query:how%20to%20get%20akonadi%20notes%20into%20plasma+page:1+mid:uvsxf
>> wpgqpor74iy+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/
>> 
> _______________________________________________
> 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/

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