...and of course for some an actual system notification might be suitable.

After giving it some though here's the current plan for the notification system:

Overview

Notifications will be the primary mechanism for user feedback. The reason for that is that our system is inherently asynchronous, and most operations may be executed at any later time, can be triggered by external processes, etc. In other words, we have no direct control over when things start to happen, yet we want to give the user feedback when things are happening.
In cases where we want to tie the user feedback to a specific action in the UI, the solution will be to use identifiers to match up a notification to the initial trigger of it.

We further want to have notifications that tell the UI what is happening without going into details to much, so we maintain a clear separation of UI and the backend. That means we i.e. really don't want to display strings that are somehow coming from the backend.
We therefore need a way for notifications to be descriptive enough that we can build a reasonable representation for it on the UI (e.g. a translatable string).

Notification

Most notifications will probably originate from Sink. Those notifications are then processed by Kube and turned into something that we can use for the UI,
so e.g. containing the necessary translatable strings etc. These notifications can then be processed by a notification handler in QML that i.e. uses it to display a popup notification.

NotificationHandlers will have to be able to filter notifications so they can show only relevant notifications in the relevant places.

For this to work we need to be able to associate notifications with various parts of the systems.

A notification therefore has the following properties:

• A general notification type: Info, Warning, Error, Status, Progress This type is used categorize a notification.
• A resource identifier: Allows to link the notification to a specific resource instance.
• A code for closer specification of the error/info type: TransmissionFailed, LoginFailed, ServerNotAvailable / TransmissionSucceeded, ....
• A action identifier: This will be an identifier that links back to the original action that triggered. We don't have that right now, so we'll need to start issuing those identifiers when triggering i.e. an addition or modification or....
• We may have to add more context to indicate when a notification applies to something more specific.

Context/Logging

For error messages we'll want to allow the user to gather more information about what exactly went wrong.
The place where that information is most likely available are the log-files.
It would therefore make sense to add an identifier to the notification that allows to retrieve the relevant logs (if any) for that incident.
This will however require that the logging system is also prepared for that.

On the highest level we have the resource identifier that allows us to filter the log for relevant content.
For a more concise filtering we'll have to add the action identifier to the logging cateory, so we can track what log entries are relevant
for that action.

Integration of notifications into models

We currently set a "virtual" status property on resource depending on the status. This allows us to hide that implementation detail from Kube, however, I'm not sure if the approach makes sense for widespread use.

Arguably it would be possible to implement many types for notifications as model properties as well:

• Message sent: Mail removed from outbox model
• Failed to send message: Error property in outbox model
• Sync status/Progress: Status property on resource
• Login error: Status property on resource

Examples

Message sent

Notification:

• Type: Info
• Resource: identifier of mailtransport resource
• Error code: 0
• Action identifier: Identifier of mail add action

Result: "Message sent."

Failed to send message

Notification:

• Type: Warning
• Resource: identifier of mailtransport resource
• Error code: TransmissionFailed
• Action identifier: Identifier of mail add action

Result: "Failed to send message."

Messages are being fetched

Notification:

• Type: Info
• Resource: identifier of syncing resource
• Error code: None
• Action identifier: Identifier of sync action

Result: An indicator that a sync is in progress.

Notification:

• Type: Progress
• Resource: identifier of syncing resource
• Error code: None
• Action identifier: Identifier of sync action

Result: Progress information

Failed to contact server

Notification:

• Type: Warning
• Resource: identifier of resource
• Error code: TransmissionFailed
• Action identifier: Identifier of sync action

Result: "Failed to reach server."

Login failed (credentials invalid...)

Notification:

• Type: Error
• Resource: identifier of mailtransport resource
• Error code: LoginFailed
• Action identifier: Identifier of sync action

Result: "Failed to login, your credentials may be incorrect."