[Kde-pim] Notes in KDE in the future

Tue Nov 3 19:52:39 GMT 2009

On Tuesday 03 November 2009 12:09:26 Stephen Kelly wrote:
> 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>

Wouldn't it be better if you could just link the file (photo or whatever) to 
the note (and the gui maybe displays it), instead of embedding it completely?
This way the file would be accessible also standalone, which would probably 
pervent some data duplication.
It would also simplify the note format, since it is then really only text.
I don't know atm. how to make a "static" link to a file in the database, but i 
guess it should be achievable somehow.

Just an idea...

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