Re: [RFC] User Notifications (long)

[Jack <ostroffjh users sourceforge net>]

Hello Albrecht,

On 2020.04.30 12:04, Albrecht Dreß wrote:
> 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 stderr.
>
>
> 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!
>
> Best,
> Albrecht.
I mostly agree, but would like the option to have the messages output  
in a way that can easily be saved to a file, which I don't know  
possible for desktop notifications.  I may not have the terminology  
correct, but what about (optionally) using the syslog mechanism, where  
the use can configure whether those messages are just included in the  
standard location (/var/log/messages for me, using openrc) or  
configurably to something like /var/log/balsa, or even  
/var/log/balsa/balsa.log and/or /var/log/balsa/balsa.err.

Just FYI, I currently have a script to start balsa which saved stdout  
and stderr to files, which just get overwritten on the next start,  
unless I save/rename them if the previous run ended with some problem.   
(I have lots of those saved for future debugging.)

However I definitely agree with any simplification and consistency in  
logging and error reporting.

Jack