[RFC] User Notifications (long)

Hi all,

this RFC is loosely related to issue #32 (<https://gitlab.gnome.org/GNOME/balsa/-/issues/32>), but I feel a 
broader discussion is required before implementing anything…

While digging through the various terminal logging mechanisms Balsa uses, I noticed that we have the 
following ways to display information to the user apart from writing to stdout and stderr:

(1) libbalsa_information* uses desktop pop-up notifications (GNotification from GIO) to display notifications 
of levels MESSAGE, WARNING or ERROR.  When called for levels DEBUG or FATAL (the latter is never used in the 
code, though), it throws a G_CRITICAL and does nothing due to a broken icon loading code.

(2) balsa_information* uses the same log levels as libbalsa_information, but here the user can configure for 
each level if the information shall be
* displayed in a separate dialogue for each message,
* displayed in a list,
* displayed in the status bar,
* written to stderr or
* ignored (dropped).

Note that there isn't even the option for a GNotification, and IMO the implementation is broken, as it 
/might/ be possible to call balsa_information*, in turn calling gtk functions like gtk_dialog_run(), from a 
thread which is explicitly forbidden (is it?).

(3) Activating the miscellaneous config option “Debug” will print a few messages, mixed to stdout and to 

IMHO, #1 and #2 should be unified, i.e. libbalsa_information* should use the configuration settings of 
balsa_information*, so we could effectively replace the calls to the balsa_information* methods by 
libbalsa_information* throughout the project:

* The desktop notification (GNotification) should be added as output option, as it is the most common way 
these days, and should probably be the default for MESSAGE, WARNING and ERROR.
* Does it still make sense these days to display a dialogue, or shouldn't we use the desktop notification 
instead?  The dialogue /might/ be a better choice for error messages, as the desktop notification may or may 
not be hidden automatically, though.
* Writing messages to stderr is useless for the vast majority of users, so we might want to drop that option 
completely?  Or at least for ERROR and WARNING messages?
* Likewise, it should not be possible to ignore (i.e. disable) ERROR and WARNING messages?
* The unused level FATAL should be removed.  DEBUG could always be printed to stdout or stderr, or even be 
changed from (lib)balsa_information* to g_debug()?

Or, as a more radical change, and as the majority of notifications actually uses libbalsa_information*, 
unconditionally produce a desktop notification for all ERROR and WARNING messages, but automatically provide 
a protocol (list) dialogue collecting all these messages with a time stamp.  The user could show the list 
dialogue from the File menu.  For MESSAGE the status bar is probably the proper target (of course, the 
respective level of the individual notifications needs to be checked…).  This removes flexibility/complexity, 
but is likely suitable for most users.  (I must admit that I tend to prefer this approach.)

Re. #3 above, IMO the option is more or less useless.  *All* messages controlled by this option should be 
converted into g_debug() calls, and the option should be removed.

As always, any input is highly appreciated!


Attachment: pgp0BZfhTdm8w.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]