Den 07. sep. 2012 15:35, skrev Patrick Ohly:
> Well, not necessarily. The Harmattan designers would probably
> foreseen such issues. If I was a Harmattan software engineer and coaxed
> into adding support for HTML descriptions in the calendar/notes, what I
> would do was to have the calendar UI first try to load the X-ALT-DESC
> (if it exists), convert it to plaintext, and compare that with the
And if they were under time pressure or wanted to avoid expensive
runtime checks, they might have decided instead to not implement this
and instead demand that the entity writing the item does the right
Hardly. It would be both cheap and trivial. I'd do this when displaying
the description, in which case they already parse the HTML anyway, which
would be far more expensive than extracting a plaintext from the
textarea afterwards (which they obviously already have a way to do, in
order to generate the DESCRIPTION in the first place). It would be a
couple of extra lines of code, and be nothing compared to the HTML
processing that happens anyway. It shouldn't have been a big deal.
> But further testing may be needed to find out if that actually
> of course...
Yes, please test.
OK, I tried to desync the two properties with "syncevolution --update"
and see what it looks like in the Notes application. (It's possible the
calendar application does it differently, but the notes were our target,
Apparently the plaintext DESCRIPTION appears in the main list view
(where the top 3 lines of all notes are shown, and you can select one).
But in the detail view, where you can see and edit the complete note,
the HTML version is shown even if it is different from the plaintext
version. Bad news, it seems. Perhaps those software engineers just
weren't that clever...