Feature: VJOURNAL support

[vuori]

I've been thinking about adding support for VJOURNAL entries to khal. AFAICT these are almost the same as VEVENT, the main difference being that they are implicitly FREE and TRANSPARENT. So it seems that this would mostly need a few UI tweaks to show/hide journal entries in agenda views and maybe allow editing long DESCRIPTIONs in an external editor.

Is there interest in having this in mainline?

(Since many CalDAV servers don't allow pushing VJOURNALs by default a nice extra would be to have a setting to create "compatible" journal entries which are VEVENTs with an X-flag to indicate that these are actually journal entries. KOrganizer has a pretty nice UI for VJOURNALs so there's some benefit to having real ones though.)

[WhyNotHugo]

What's your intended use case for the journal entries? I have no objection to them that I would like to understand what use case we are trying to address.

[vuori]

"What I did today" journal/diary type entries in a more verbose and unstructured format than what VTODOs allow for. Basically what RFC 5545 § 3.6.3 suggests: "descriptive text notes associated with a particular calendar date." I have been using a text file for this, but having journal entries show up in my calendar would be nice.

[WhyNotHugo]

Oh, cool. I've been thinking about using VJOURNAL for things like this too -- I hadn't though if using khal for it though. Does it make sense for these entries to be shown on the same calendar views? I'm somewhat undecided (but not opposed to it).

[vuori]

As precedent, KOrganizer (which has pretty advanced support) shows journal entries in calendar/agenda with a notebook icon. Orage only shows them in a separate listing of journal entries, though that's a sub-view of the selected date's details. There seems to be little support elsewhere. One alternative I was thinking of was a three-way flag -J/--journal (with a configurable default) for at/calendar/list/search and ikhal: "yes" to show both VEVENT and VJOURNAL (default), "no" for VEVENT only, "only" for VJOURNAL only. The other way would be to have --journal be a yes/no boolean for existing subcommands plus a separate "journal" subcommand to show a list of journal entries. While this is a bit non-orthogonal, it would allow having a separate default time range: seeing journals for the last year or month seems like the most useful default view (you rarely care about past VEVENTs while you rarely have future VJOURNALs, so existing calendar/list default ranges are not too useful). From a technical perspective, I was going to integrate this with khal because VJOURNAL is almost exactly a VEVENT with just a few different defaults. It's also almost the same conceptually: a summary and description attached to a date (unlike a VTODO which is conceptually quite different, since todos involve all sorts of priority and completion status bits and may not have dates at all). Implementing journals as a whole separate project would involve quite a bit of duplicate work in both UI and internals.

[WhyNotHugo]

I guess there's no reason to not show then in khal's views. I suppose some kind of icon could identify them (maybe configurable? that can be done later tho).

Do you think the same UI for creation makes complete sense? You'd never want alarm (right?) Are invitees a thing?
I do agree that there's a lot of UI to be reused tho, so keeping it in the same project makes sense.

[vuori]

Some functions in new/edit should be disabled. VALARM is not allowed, but attendees can be added (supposedly for indicating who was present at a meeting that the journal entry applies to). They should not get invitations though. I don't see it in the current UI, but free/busy and opaque/transparent selection are also not applicable. Recurrences are technically allowed, though it's hard to imagine why you'd want a recurring journal entry. Maybe to use as a template for recording some kind of weekly meeting? Only IETF knows I guess. They would probably be better off disabled. Usually a journal will have a long description, so a key binding to invoke an external editor to edit either single fields or just a summary+description (separated by newline) combination seems desirable. Anyway I haven't even looked at khal's code yet so I guess I'll get to that soonish.

[NickHastings]

Just wanted to chime in and add a little more about the use case. Implementing this would allow synchronization with notes in jtx Board on Android.

[vuori]

Sorry for not getting back on this. Unfortunately this project is stalled and is unlikely to proceed for now.

Adding VJOURNAL support to the backend was quite easy, and basic viewing support was also mostly unproblematic. The big issue turned out to be the create/edit UI: journals involve long DESCRIPTION fields with embedded newlines, and in typical use, the incremental editing of these fields. The major editing modalities (CLI, prompt-based, TUI) are either not really suited to this use at all (the first two) or would require a largish amount of work to handle long text fields well (TUI).

I think dealing with the edit UI question would require some amount of refactoring and a comprehensive vision of how the various editing modalities should work as whole, and I'm not equipped for either task. If there's interest, I can rebase and submit the backend/model side code.

[piater]

How about calling out to $EDITOR?