Den 07. sep. 2012 15:35, skrev Patrick Ohly: >> Well, not necessarily. The Harmattan designers would probably have >> 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 >> DESCRIPTION. > > 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 > thing ;-)
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 happens, >> 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, I suppose.) 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... _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
