By design, KAlarm stores all its alarms in VEVENT, and in order to provide all its functionality it uses quite a few custom properties in VEVENT and VALARM. Giving full support to VTODO would be outside the current scope of KAlarm, whose purpose is to provide reminders. Adding todo functionality would almost certainly need significant user interface changes in addition to logic changes.

It might be possible to add import (read-only) support for VTODO. This would need to convert them to VEVENT. I don't know how practical this would be, and I don't think the work would be justified unless there was evidence that people would actually use that facility. Of course, if you wanted to implement something yourself along these lines, I'd be happy to consider incorporating that into KAlarm, and could point the way to how to go about it.

(In reply to David Jarvie from comment #1)
> By design, KAlarm stores all its alarms in VEVENT, and in order to provide
> all its functionality it uses quite a few custom properties in VEVENT and
> VALARM. 

Perhaps I have a wrong understanding of the function of KAlarm within the KDE ecosystem.

I perceive it as a reminder application which would serve well – and with better functionality
than »korganizer« (or the patch by David) ever provided – as substitute for the notifications
(see https://bugs.kde.org/show_bug.cgi?id=481024).
(Better, namely: the preview of impending alarms, the overview over recent alarms, command alarms, … more)

IMHO it is neither a substitute for a calendaring application nor a todo list.

What is your intended usage of KAlarm?

> Giving full support to VTODO would be outside the current scope of
> KAlarm, whose purpose is to provide reminders.

VTODOs contain VALARMs with the exact same syntax and semantics
as VEVENTs. (There are only minimal differences between VTODOs and
VEVENTs anyhow – they are practically fraternal twins. The only differences
coming readily to my mind are "transparency" and "dtend" for VEVENTs and 
"percentage completed" and "due" for VTODOs – all seemingly not used by KAlarm anyhow.)
(see https://www.rfc-editor.org/rfc/rfc5545#section-3.6.1 and https://www.rfc-editor.org/rfc/rfc5545#section-3.6.2)

I only suggest to honor the reminders in the VALARMs of both ICAL-entry-types
to make KAlarm an universal reminder for all ICAL-entry-types having reminders
i.e. VALARMS …

> Adding todo functionality
> would almost certainly need significant user interface changes in addition
> to logic changes.

That is not my intention at all – only reminders.

> It might be possible to add import (read-only) support for VTODO. This would
> need to convert them to VEVENT. I don't know how practical this would be,
> and I don't think the work would be justified unless there was evidence that
> people would actually use that facility. 

Trivial. The only difference between VTODO and VEVENT for the purpose of
KAlarm is, if the time period is not given via DTSTART and DURATION (identical for both) 
but by start and end time, then for the end time
* VTODO uses DUE
* VEVENT uses DTEND 

(Actually users knowledgeable about the ICAL format have an unexpected nasty surprise 
if KAlarm handles only alarms of VEVENTs because they are for many purposes completely
interchangeable with VTODOs …)

> Of course, if you wanted to
> implement something yourself along these lines, I'd be happy to consider
> incorporating that into KAlarm, and could point the way to how to go about
> it.

Point me ;-)

As stated in its handbook, KAlarm is designed as a personal message, email and command scheduler. It is not designed for group use. It aims to present a simple interface (unless the user chooses to expand the options displayed) to allow ordinary (i.e. non-technical) users to schedule alarms. Most users only use it with its default calendars, and not with any calendars created by other applications. The fact that KOrganizer reminders have been messed up in recent times is unfortunate, but I don't want KAlarm to be amended or expanded in any way in order to be used as an adjunct to KOrganizer to provide its reminder functionality. It's up to KOrganizer to sort out its own deficiencies.

For these reasons, I don't see it as important to provide KAlarm with the ability to read VTODOs, but I wouldn't object. It would be important to first of all decide on how reading calendars containing VTODOs should fit into KAlarm's user interface. As I said previously, I would see it as being via some sort of import function, but I don't know whether that would satisfy your goal of users not being surprised when VTODOs are ignored if KAlarm is told to use a calendar which it didn't create itself. Bear in mind that if VTODOs were edited in KAlarm, or if they contained recurrences, they would need to be rewritten as VEVENTs (and of course, functions specific to todos would be not show in KAlarm).

(In reply to David Jarvie from comment #3)
> As stated in its handbook, KAlarm is designed as a personal message, email
> and command scheduler. It is not designed for group use. 

I do not intend group use – only personal reminders.

The option to schedule commands is very valuable and much needed, especially
as it seems to be scratched elsewhere in KDE.

> It aims to present
> a simple interface (unless the user chooses to expand the options displayed)
> to allow ordinary (i.e. non-technical) users to schedule alarms. 

Which it does very well.

(But the existence of a command scheduler aims at technical users, IMHO – unless we have a very different definition ;-)

> Most users only use it with its default calendars, and not with any calendars created
> by other applications. 

But you provide both for import of ICS files as well as r/w and r/o access to other ICAL calendars.
VTODOs are integral part of the RFC 5545 specification as are VEVENTS, both using the identical 
VALARM substructure for reminders – users are bound to expect, that reminders reminders in
ICAL/RFC-5545-conformant calenders work, ie. in reminders in their todos
work the same as within their events, when importing ICS files.

The change is trivial and probably very small – please point me to the place and provide some
guidance, and I will do this …

> The fact that KOrganizer reminders have been messed
> up in recent times is unfortunate, 

Polite understatement of the week ;-)

> but I don't want KAlarm to be amended or
> expanded in any way in order to be used as an adjunct to KOrganizer to
> provide its reminder functionality. 

KAlarm as reminder system is much better than anything I've seen so far.
The unique advantages, I personally see, are:
* (optional) list of recent reminders triggered – very valuable when you lose track on a stressy day
* lookeahead of upcoming reminders – very valuable to e.g. shift them proactively if you need some undisturbed time or to preemptively do tasks if a meeting is cancelled
* color-coding of reminders
* command execution reminders

As such it could improve on any existing calendaring and todo application and act as central reminder application.

There a two independent avenues of interfacing:

1. (essential) enable snoozing alarms triggered by read-only ICS calendars – IMHO a very small and simple change: the snoozed reminder is copied to KAlarms standard active calendar (it should be even possible to have a reference to the original). 
This change would easily integrate all RFC-5545-conformant ICS calendar based applications (their reminder function could be switched of by the user …)

2. (optional) listen on the D-BUS for notifier events (»org.freedesktop.notification«) – this probably is some effort, but the change is well isolated new functionality. Code for listening on the D-BUS for this events, more or less filter logic, creating reminders from templates configured for specific notification types. Besides reacting to calendar reminders this opens up many other use-cases. 
This would work in any desktop environment having a D-BUS and conforming to the relevant parts of the freedesktop standard (ie. most).
On any desktop without facility to run commands in reaction to notifications KAlarm would be greeted by any user sophisticated
enough to automate their workflows – eg. on KDE (the facility is crippled to be mostly useless in 5 and shall be dropped in 6 …)

If you completely oppose these ideas, I will not bother you further in this direction.
If you are interested, I will help as much as I can.

> It's up to KOrganizer to sort out its own deficiencies.

I would be more than happy, if KOrganizer would just stop willingly introducing new ones ;-)

> For these reasons, I don't see it as important to provide KAlarm with the
> ability to read VTODOs, but I wouldn't object. It would be important to
> first of all decide on how reading calendars containing VTODOs should fit
> into KAlarm's user interface. 

No change needed in the interface at all.

For processing you are using »kcal«, which out of the box should – as any RFC-5545-conformant library – be fully capable to handle this correctly anyhow.

> As I said previously, I would see it as being
> via some sort of import function, but I don't know whether that would
> satisfy your goal of users not being surprised when VTODOs are ignored if
> KAlarm is told to use a calendar which it didn't create itself. Bear in mind
> that if VTODOs were edited in KAlarm, or if they contained recurrences, they
> would need to be rewritten as VEVENTs (and of course, functions specific to
> todos would be not show in KAlarm).

Please kindly point me to the code, where you do the processing of VEVENTS, and I
will provide solid and concrete technical answers.

Yes, KAlarm is for both technical and non-technical users, but to serve the latter, it needs a simple interface. More advanced users can expand the range of displayed options, and use such things as command alarms.

Currently, if the user configures KAlarm to access in read-write mode a calendar which has been created by another application, KAlarm will write its own custom properties into the VEVENTs and VALARMs in order, for example, to track when recurrences were last triggered by it. If alarms are subsequently created or edited, they also will contain KAlarm custom properties. If the user also accesses the calendar file from another application such as KOrganizer, the KAlarm specific data may or may not survive, so this could alter how KAlarm functions for these alarms.

Having thought about what you've said, I realise that KAlarm could handle alarms within VTODOs similarly to those in VEVENTs, and update them with its own custom properties to keep track. There isn't any need to copy VTODO alarms into VEVENTs - they can just stay in the VTODOs, and KAlarm would simply ignore the todo-specific data.

Consideration would need to be given to:

1) How to handle VTODOs with multiple alarms. Currently, KAlarm stores each user-configured alarm in a separate VEVENT (although it often creates multiple VALARM instances within the VEVENT to handle different aspects of what to the user is a single alarm: for example, a display alarm which also plays a sound would contain a VALARM for display and a VALARM for sound, but there are other less obvious reasons to have multiple VALARMs). This scheme would not be able to handle two completely separate alarms in a VTODO (and indeed doesn't handle two completely separate alarms in a VEVENT either).

2) When a VTODO alarm is edited in KAlarm, should it be saved as a replacement VTODO? I presume yes.

3) It isn't just snooze information which currently isn't stored for read-only calendars. Also, data on the last triggered recurrence would be needed in order for read-only alarms to operate in the same way as read-write ones. I suppose that snooze data could perhaps be stored in KAlarm's default calendar, and if when the snooze expired the original read-only alarm or calendar was no longer available, the snooze would be ignored and the snooze data deleted. I'm less sure about keeping recurrence trigger data in the default calendar, since that is much longer lasting, but in principle it could also be done (as long as it is deleted if the read-only alarm or calendar becomes unavailable).

4) I don't understand what you are proposing about D-BUS events/notifications. Do you mean events/notifications not sent to KAlarm? If so, what types? Also, if you're saying that this stuff wouldn't work on KDE, then I don't think it really belongs in a KDE application.

You can see descriptions of all the KAlarm custom properties in DESIGN-kalarmcalendar.html in the top level of the KAlarm source directory.

(In reply to David Jarvie from comment #5)
> Yes, KAlarm is for both technical and non-technical users, but to serve the
> latter, it needs a simple interface. More advanced users can expand the
> range of displayed options, and use such things as command alarms.

A good solution.

> Currently, if the user configures KAlarm to access in read-write mode a
> calendar which has been created by another application, KAlarm will write
> its own custom properties into the VEVENTs and VALARMs in order, for
> example, to track when recurrences were last triggered by it. If alarms are
> subsequently created or edited, they also will contain KAlarm custom
> properties. If the user also accesses the calendar file from another
> application such as KOrganizer, the KAlarm specific data may or may not
> survive, so this could alter how KAlarm functions for these alarms.

(My answers rest on https://github.com/KDE/kalarm/tree/master/src – 
I hope this is the correct repository (it still has Akonadi-calls in it and you 
mentioned the docs where outdated, because Akonadi support was dropped …))

As your custom properties have the RFC-conformant custom property prefix 
you at least have done anything possible to make it work – but of course you
are right: alas that is no guarantee …

For KOrganizer I can report: it works correctly with an ICS file both share in R/W mode.
(Both detect if the other application changed content and reread the file, but of
course there are no provisions for avoiding concurrent changes (which would either corrupt the file or loose changes of one application) – but careful handling by the user …))
(Therefore my question about ICAL directory calendar sources – they, for various reasons, reduce this risk significantly …)

Actually, there might be a really good solution for this: 
The "Related To" property (see https://www.rfc-editor.org/rfc/rfc5545#section-3.8.4.5).

KAlarm would then generate a dependent object (child), referencing back to the parent object in the r/o ICS of the other application.

With any luck »kcal« already has implemented it, and might even has a complete view of all calendars within KAlarm, so that it just works …

In effect the child would have access to changes of the parent, especially deletion or start/end changes (for relative alarms) and any need to write anything back into the shared ICS would vanish …

> Having thought about what you've said, I realise that KAlarm could handle
> alarms within VTODOs similarly to those in VEVENTs, and update them with its
> own custom properties to keep track. There isn't any need to copy VTODO
> alarms into VEVENTs - they can just stay in the VTODOs, and KAlarm would
> simply ignore the todo-specific data.

We are on the same page.

> Consideration would need to be given to:
> 
> 1) How to handle VTODOs with multiple alarms. Currently, KAlarm stores each
> user-configured alarm in a separate VEVENT (although it often creates
> multiple VALARM instances within the VEVENT to handle different aspects of
> what to the user is a single alarm: for example, a display alarm which also
> plays a sound would contain a VALARM for display and a VALARM for sound, but
> there are other less obvious reasons to have multiple VALARMs). This scheme
> would not be able to handle two completely separate alarms in a VTODO (and
> indeed doesn't handle two completely separate alarms in a VEVENT either).

RFC 5545 not only allows but advocates that VEVENT/VTODO can each have multiple VALARMs with absolute or relative time specifications triggering at different points in time (and actually each VALARM can have its own summary and description, which is useful for some use-cases (example see below)).

KAlarm should be capable to cope with this and the ICAL library may already is …

> 2) When a VTODO alarm is edited in KAlarm, should it be saved as a
> replacement VTODO? I presume yes.

Well, KAlarm has its native entries (via command line parameters, via its own GUI, via imported ICSes or perhaps in the future from D-BUS messages – see below). For these of course: yes.

Then it has external entries from ICS files shared with another ICAL-aware application.

I can imagine many use-cases where KAlarm and the other application act as peers, both writing changes back with collision avoidance done by some outside mechanism.

Finally I see some asymmetric use-cases where KAlarm is ancillary as a reminder manager for a calendaring application.
The calendaring application is the owner/manager of the events and todos – and the place for editing them.
KAlarm allows fine-tuned managing of the reminders and has r/o access to the calendar of the other application.

Technically I hope "Related To" works as solution.

From the user's point of view:
When a "Related To" alarm is edited, the GUI shows the summary and description of the event/todo as read-only together with some hint of the managing application (typically indicated in the ICAL file) and the external calendar and an indication that the event itself must be managed there, whereas KAlarm only manages the reminder. The timing, summary (name), and description (message) of the alarm proper can still be edited by the user as normal. 

> 3) It isn't just snooze information which currently isn't stored for
> read-only calendars. Also, data on the last triggered recurrence would be
> needed in order for read-only alarms to operate in the same way as
> read-write ones. I suppose that snooze data could perhaps be stored in
> KAlarm's default calendar, and if when the snooze expired the original
> read-only alarm or calendar was no longer available, the snooze would be
> ignored and the snooze data deleted. 

Again "Related To" hopefully solves this for us.

> I'm less sure about keeping recurrence
> trigger data in the default calendar, since that is much longer lasting, but
> in principle it could also be done (as long as it is deleted if the
> read-only alarm or calendar becomes unavailable).

We have two types of recurrences: 
Recurrence definition of the VEVENT/VTODO itself, and recurrence definitions within a VALARM.

I give a practical us-case example to make the discussion more concrete:

Here, cars have to have a technical inspection every 2 years. 
In my calendaring this is a todo, recurring every 2 years, starting with the first of the relevant month and due with the end of this month. 
(I use a todo as an event would visually clutter a whole month …)

A VALARM is set to remind me one month in advance before the start.

If this alarm is reported by KAlarm – say on a late friday afternoon – I know that calling the garage will be in vain till Monday. So I defer the alarm accordingly – solely within KAlarm without any change in the todo (which sits protected in a r/o calendar anyhow, waiting to trigger again in 2 years).

Let's say on Monday their answering machine tells me, they are on vacation till next Monday.
I defer the alarm again, by 1 week and 1 day (i.e. till Tuesday), because next Monday they will be flooded by calls. Perhaps I lay down some short note in the alarm description, why I postpone till Tuesday (still leaving the actual todo unchanged, because this note only applies to the current year and my current workflow, which is managed by KAlarm).

Say, on Tuesday we fix a date for the inspection: I add an event (showing up in the calendar view) at the date in my calendaring application with some appropriate reminder setting and close/deactivate the alarm within KAlarm, because it has fulfilled its job.

When the reminder for the car inspection triggers, I tidy up the car for inspection, and set a deferred alarm for driving the car to the garage.

Let's discuss within the workflow of this use-case.

If a calendar is used in PARENT/CHILD mode I would ignore the recurrences of the event/todo – this is the sole responsibility of the parent calendaring application as it has nothing to do with reminder management and KAlarm is NOT the owner of the event, just of the reminder.

I'm unsure about recurrence definitions in the VALARM stanzas – I've never used them and personally see no real use-case, because I delay my reminders according circumstances – as lined out above. But may I'm just not imaginative enough. Therefore I'd suggest to honor recurrences with VALARMs within PARENT/CHILD mode.

With native KAlarm events I'd actually would see good uses for VALARM recurrences, anyhow.

> 4) I don't understand what you are proposing about D-BUS
> events/notifications. Do you mean events/notifications not sent to KAlarm?

Yes.

> If so, what types? 

Probably solely/mainly those addressed to »org.freedesktop.notification«.

Here two sample use cases:

1. capture reminders send to the desktop notification service by calendaring applications
This implements are more loose coupling than the "Related To" approach and allows interfacing with calendaring applications not using ICAL files. The user would configure KAlarm to act upon the D-BUS message (by configuring a template with an D-BUS filter expression – the template being populated by the content of the DBUS message and instantiated into an alarm). To avoid double notification the user may silence the corresponding notifier action in the desktop notifier.

2. react upon events like loosing contact to a bluetooth device and the like
This specifically could – together with a command alarm – implement something like »bluelock«, i.e. screen-locking a device when separated from a bluetooth token (smart watch, headset, etc.) worn by the owner.
(I know, 
2.1 this is not completely secure, as the bluetooth connection could be relayed over quite a distance by a skillful opponent – nevertheless it is a useful precaution against random theft or spying …
2.2 actually that is a job for UDEV. While I dauntlessly edit UDEV rules (always with the documention in view ;-), I know many technical users (rightfully claiming this category) which wont … And UDEV works system-wide (ok, for my laptops), while KAlarm would easily allow user-login-session specific actions …

If you find this interesting, I'd go into technical detail.

> Also, if you're saying that this stuff wouldn't work on
> KDE, then I don't think it really belongs in a KDE application.

Technically there is absolutely no obstacle.
The existing functionality is just arbitrarily removed by solitary short-sighted unimaginative decision making …
(see https://bugs.kde.org/show_bug.cgi?id=481068 and https://bugs.kde.org/show_bug.cgi?id=481069)

Many of your proposals go beyond the intended scope of KAlarm, and if implemented would expand its function from being a stand-alone personal alarm application to something more general. This would add more code complexity, and therefore more maintenance overhead, which I don't think are desirable for the application as it is designed. Specific comments are below.

> (My answers rest on https://github.com/KDE/kalarm/tree/master/src

I don't know the status of that repository. The correct one is at https://invent.kde.org/pim/kalarm .

> The "Related To" property (see
> https://www.rfc-editor.org/rfc/rfc5545#section-3.8.4.5).
> 
> KAlarm would then generate a dependent object (child), referencing back to
> the parent object in the r/o ICS of the other application.
> 
> With any luck »kcal« already has implemented it, and might even has a
> complete view of all calendars within KAlarm, so that it just works …
> 
> In effect the child would have access to changes of the parent, especially
> deletion or start/end changes (for relative alarms) and any need to write
> anything back into the shared ICS would vanish …

I think that for simplicity, I'd prefer to treat read-only calendars as they are currently. They lack functionality in certain respects, but I would regard this as "user beware", since they are not a common usage.

> RFC 5545 not only allows but advocates that VEVENT/VTODO can each have
> multiple VALARMs with absolute or relative time specifications triggering
> at different points in time (and actually each VALARM can have its own
> summary and description, which is useful for some use-cases (example see
> below)).
> 
> KAlarm should be capable to cope with this and the ICAL library may already
> is …

The ical library does cope with this. However, KAlarm always creates a separate VEVENT for each alarm, and this is a fundamental assumption in its design. It would add considerable complexity to cater for a read-write calendar containing events with multiple alarms but again because this can only happen with calendars created by other applications, which is not the usual use case, I would be against catering for multiple independent alarms in the same VEVENT. 

Multiple alarms in a VEVENT or VTODO could be catered for an import function instead, which would split such instances into multiple VEVENTs or VTODOs, so as to conform to what KAlarm is designed to use. If a user tried to configure KAlarm to access a calendar containing such instances, the user could be prompted to import it, with a warning that otherwise, some alarms would be ignored.

> I can imagine many use-cases where KAlarm and the other application act as
> peers, both writing changes back with collision avoidance done by some
> outside mechanism.

For KDEPIM applications, that would require reverting to using Akonadi as the backend interface. This is out of the question since the use of Akonadi in KAlarm version 2 resulted in continual difficult to fix bugs, which is why a new direct file interface was developed for KAlarm version 3.

> Finally I see some asymmetric use-cases where KAlarm is ancillary as a
> reminder manager for a calendaring application.
> The calendaring application is the owner/manager of the events and todos –
> and the place for editing them.
> KAlarm allows fine-tuned managing of the reminders and has r/o access to the
> calendar of the other application.
>
> Technically I hope "Related To" works as solution.
> 
> From the user's point of view:
> When a "Related To" alarm is edited, the GUI shows the summary and
> description of the event/todo as read-only together with some hint of the
> managing application (typically indicated in the ICAL file) and the
> external calendar and an indication that the event itself must be managed
> there, whereas KAlarm only manages the reminder. The timing, summary
> (name), and description (message) of the alarm proper can still be edited
> by the user as normal.

This is all out of scope, as explained in my first paragraph.

The rest of what you suggest is also out of scope. If users want to use KAlarm to manage their alarms in place of their calendaring applications (can't they find calendaring applications which handle alarms?), they will need to import them or set them up manually in KAlarm.

(In reply to David Jarvie from comment #7)
> Many of your proposals go beyond the intended scope of KAlarm, and if
> implemented would expand its function from being a stand-alone personal
> alarm application to something more general. This would add more code
> complexity, and therefore more maintenance overhead, which I don't think are
> desirable for the application as it is designed. Specific comments are below.

Thank you for speaking your mind and explaining the intended scope for your application.

I speak my mind in turn and explain the foundations of my suggestions:

In the eighties I've choosen the philosophy underlying UNIX and IP as my professional basis:
Build small versatile tools, interoperable by common open protocols and formats, and create
quickly solutions from this as new problems turn up.

IMHO this is the most successful computational philosophy so far, which – against all odds –
made unixoid systems dominant in the server world. X11-based GUI, especially KDE, were
long following this philosophy and actually, IMHO, there was a window of a few years, where 
they might have become significant on the desktop, too. Alas, GNOME and KDE, IMHO departed
from this philosophy …

In your application I saw potential to increase versatility – but if this is not your cup of tea, this
is OK with me and, as promised, I stop proposing this idea.

Thank your for your work and time so far!

I'm well aware of the benefits of how UNIX tools can work together to do more complex tasks, which for example allows versatility in scripting. But GUI applications as they currently exist generally don't lend themselves to this, due in part I'm sure to the need for user interaction using a mouse. Certainly, I would classify KAlarm as a non-UNIX type tool since it has been developed with its design tailored to a specific type of use and assumptions, which doesn't make it easy to expand it into a more general tool. Specifically, it is designed to use ICAL in a restricted way, and never with the aim of allowing it to expand to handle the full range of ICAL alarm functionality.

It's interesting to have your ideas - thank you. Even if some are out of scope for KAlarm's intended use, others do provide some ideas for future development.

(In reply to David Jarvie from comment #9)
> I'm well aware of the benefits of how UNIX tools can work together to do
> more complex tasks, which for example allows versatility in scripting. 

I do not doubt that you are aware of this – nevertheless practice and experience changes the awareness: I use these mechanisms from the early eighties – roughly 4 decades – more or less on a daily basis, all the while monitoring my computer usage and refactoring it into automatable sub-tasks …

I use this not only for scripting but my command-lines regurlarly contain pipes, variables, history references, redirections, …

> But GUI applications as they currently exist generally don't lend themselves to
> this, due in part I'm sure to the need for user interaction using a mouse.

IMHO a misconception:
The CLI needs interaction too – no command executes without pressing the enter button, not to speak of the arcane key-press sequences needed before to have a command doing anything complex.

The core is clever inter-process communication and the pipe as well as environment variables are an ingeniously clever IPC mechanism.

With this and some scripting you can go a long way with existing GUI applications:
I have large test-beds which fire up an editor for documentation, the load generators and performance monitors (both visual and more detailed non-visual). With a keyboard macro in »vi« you trigger both a screenshot as well as a timestamp (more precise: the name of the screen-shot) and can document the observations. You close the editor – the tests are stopped, performance data is collected, processed in various ways and presented visually in GNUplot sessions as graphs which interactively can be fine-tuned, e.g. by selection of time periods, annotations, manual fitting of the parameters of mathematical models of the investigated systems, etc.
(From the tool choices you easily see: these test-beds are decades old and used since ;-)

From the outside this looks like an elaborate framework or application – but it isn't.

IPC directly between GUI applications is of course more difficult. 

From the era of mainframes (which had no GUI but monolithic applications) we have the concept of "user exits":
Specific actions like opening or storing or application-internal transformations can be configured to be done by calling external programs. Easy and effective – I know some really large applications (>500 developer years) in a technically very challenging environment which even nowadays use this intensively.

Shared storage is easy, too – be it common file formats (and some form of race condition prevention), data bases or service like »akonadi« (a good idea implemented l…ess than optimal …).

D-Bus is, IMHO, a very clever approach of IPC for GUI application, alas, not very well accessible from scripting … but with a lot potential.

> …
> It's interesting to have your ideas - thank you. Even if some are out of
> scope for KAlarm's intended use, others do provide some ideas for future
> development.

I'm looking forward to these future developments.