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.
Attachment:
pgp0BZfhTdm8w.pgp
Description: PGP signature