[Kde-pim] Notes in KDE in the future

Stephen Kelly steveire at gmail.com
Tue Nov 3 11:09:26 GMT 2009


Brad Hards wrote:

> On Monday 02 November 2009 23:28:33 Stephen Kelly wrote:
>> 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.
> I'll just throw in a couple of comments about how notes are handled in the
> exchange protocol (i.e. will need to be converted to in the openchange
> resource). 

Cool, thanks for the input.

> A note is just like an email or appointment - conceptually its
> a row in a table on the server, where the columns are different properties
> (of distinct types, and possibly multi-valued). The difference is in what
> properties are allowed / required for each type of groupware object.
> 
> Notes in exchange (and hence outlook) are basically sticky note
> equivalents. They have (in addition to the standard things every groupware
> object has): 
> 1. a suggested background colour (blue, green, pink, yellow
> or white), although in some versions of outlook the note category takes
> precedence over this property.
> 2. A size (height / width, in pixels) and a position (x / y, in pixels)
> for display.
> I haven't yet investigated what outlook will do if they aren't present.

Hmm, colour, size and position are also the things that we'll want to 
support in akonadi notes. I was going to store them in the plasma 
configuration only, but if exchange would want to store them too, it might 
make sense to put them in custom headers in the mime messages.

> 
> The note is supposed to have a subject (presumably a short summary of the
> note). Outlook notes are plain text, but servers can often convert HTML or
> RTF representations - probably need to test this.
> 
> No attachments (the spec says MUST NOT, so presumably that will cause
> problems with some form of outlook or exchange server).

Interesting. Is it impossible to say, drag and drop an image into a note 
which is stored in exchange?

I'm not certain if supporting images/embedded media is definitely the right 
thing for desktop sticky notes, but I think it is something that would make 
sense in kjots. On the desktop small makes sense, but having a big image in 
the note might make a note necessarily bigger. That could mean having some 
separation between rich text only and embedded media notes with convert 
to/move to/copy to actions, which is not so appealing.
</braindump>


>  
> [If you're interested in the spec, a google search for MS-OXONOTE will
> probably produce a link to MSDN, where you can view it in HTML or download
> the PDF].
> 
> I'm reasonably comfortable that I can extend the server object set to
> support arbitrary objects, although obviously outlook won't show the
> interesting bits.
> 
>> 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.
> So the concept here is that a backend can provide whatever MIME format it
> can handle (which might be just text/plain) and kjots will display it.

Yes. Well, almost. Whatever mimetype it wants would be too broad. I would 
say restrict it to just text/plain, text/html and maybe multipart/related, 
and try to get support for the three in any note taking application.

> 
>> 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.
> Exchange / openchange can also do notes in arbitrary folder structures.

Cool, good to know.

>  
>> 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.
> Do you have an example of what the convenience API would look like?

Nope sorry. Haven't thought that far ahead yet. It might be just an 
extension of QTextDocument which wraps a KMime::Message. QTextDocument has a 
lot of features we're not taking advantage of yet.

>  
>> 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.
> Stupid static strings is probably a fair assessment, but some of us don't
> have nepomuk everywhere. So support for using simple static strings (even
> if they get converted in awesome nepomuk strings later) is probably
> important.

I see. Which applications would not have access to Nepomuk? I have no idea 
if kde applications on windows can use Nepomuk, or do you mean non kde 
applications?

> 
> I cut a bit of nepomuk stuff here that I don't understand fully, but I do
> have a question about what the user sees. Lets say I have two separate
> desktops (e.g. work and home), and I can (somehow) access my work
> groupware server from both desktops (and perhaps some extra stuff like my
> private IMAP account, and the gmail account that gets the
> not-safe-for-work stuff). However I don't have a common filestore. If I
> create some tags on a note at work, what do I get at home?

My understanding of Nepomuk, which might be a bit cloudy, is that it handles 
local annotations/relations. If I tag an email in kmail which happens to be 
on an IMAP server, and then access that email from another application on a 
different computer, the other application will not know anything about the 
tag.

However, we could also conceivably define some custom headers in the mime 
messages like 

X-Note-Tags: giraffe,zoology

or something similar for Nepomuk annotations to indicate such things in a 
transferable way. Then if you tag a note in a commonly accessible location 
with giraffe on your work computer and other applications can process the 
tag, it could be made to have the same tag when accessed anywhere.

So it's possible, but we'll have to see if it makes real sense or if people 
want it like that. I do prefer the idea of tasks instead of tags, and 
supporting both would probably be overkill, especially as applications would 
need to have user interfaces for both.


All the best,

Steve.

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



More information about the kde-pim mailing list