[Kde-pim] KNotes issues

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Freitag, 3. August 2007 schrieb Allen Winter:
> On Wednesday 01 August 2007 9:42:14 am Reinhold Kainhofer wrote:
> > Am Mittwoch, 1. August 2007 schrieb Allen Winter:
> > > On Tuesday 31 July 2007 8:58:21 pm Reinhold Kainhofer wrote:
> > > > Am Mittwoch, 1. August 2007 schrieb Allen Winter:
> >
> > I'm rather proposing to add a property parameter X-KDE-RICHTEXT to the
> > DESCRIPTION property:
> > BEGIN:VEVENT
> > DESCRIPTION;X-KDE-RICHTEXT=HTML:<qt><b>description</b> of the event</qt>
> > END:VEVENT
>
> I have this working now.

Great!

> A couple of questions before I commit:
>
> 1. would the property parameter be better as "X-KDE-TEXT=HTML" ?
>     theoretically, allowing different types of text besides HTML?
>     not that I have any idea what that would be.. ODF? :)

How about X-KDE-TEXTFORMAT?
I don't think ODF is possible, because the description property value is 
pure-text, not binary. 
However, XHTML, RTF or all kinds of wiki markup come to mind. I'm not saying 
we should implement any of them, but the specification of the parameter 
should allow such extensions later on.

> 2. I am supporting rich text for the description, summary, and location
>     incidence properties.  

The summary might create problems:
1) We currently use a simple line edit, so we don't have an editor for it.
2) Summary is defined as a one-line summary, so line breaks and block-level 
elements are not allowed. The problem is that allowing rich text (or html) 
allows things like <br> in the summary, or even <ul><li>Point1</li></ul>
3) We'd need a html painter to draw the summaries onto the agenda items 
(currently, journals are not shown in the agenda view, but sooner or later 
they might...)
4) Usually the summary is displayed as <h1>Summarytext</h1>. If the summary is 
already html, that might terribly break the html engine/display.


>     OK?  I could probably go crazy and support 
>     rich text on categories and alarm descriptions and all sorts of stuff.
>     Suggestions for other incidence properties that should support
> richtext?

I don't think we should implement things just because we could. I suppose 
description and location (e.g. for driving directions given as lists, or to 
include an image) are enough. 


> PS.  i will award a small cash prize to anyone who rewrites the ical
> library in C++ the "KDE way" :)  With good documentation... actually, it is
> pretty darn good code.  just not documented and not KDEish. and not C++.

Fully agree! 

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGs0nSTqjEwhXvPN0RAl3eAKCW0/Kp2l6YG/5OW6cWUaUvXbGdIACg0tFV
/4RbQSBu9gt8EnMhA7YI/VY=
=DMib
-----END PGP SIGNATURE-----
_______________________________________________
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/