Hi Jack, thanks a lot for your reply!
Am 30.04.20 18:29 schrieb(en) Jack via balsa-list:
On 2020.04.30 12:04, Albrecht Dreß wrote:
[…]
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.)
[…]
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.
If you are referring to the “radical approach” above, my idea would be a (by default hidden) dialogue with a text buffer, to which *every* notification would be added as a single line, like “[time stamp] [ERROR|WARNING] [message text]”. Of course, it should be possible to select/copy/paste the data, or to save it to a file.
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.
We actually use syslog (with facility LOG_MAIL) for logging messages sent by balsa to a SMTP server, basically for tracking the message-id and queue ID reported by the remote MTA for debugging. The drawback is that (a) the log files are typically readable for the superuser only, and (b) they will mix the messages from all users in a multi-user environment. This is fine for the (relatively) few SMTP data outlined above, but will simple “explode” if we log all output Balsa produces now.
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.)
Related to issue #32, I think I will convert almost all output written to stdout and stderr into g_debug() messages with more log domains. IOW, you will have a finer control about what ends up in the logs by setting the G_DEBUG environment variable accordingly. Thanks again for your input, Albrecht.
pgpy72W4dhfMQ.pgp
Description: PGP signature
_______________________________________________ balsa-list mailing list balsa-list@gnome.org https://mail.gnome.org/mailman/listinfo/balsa-list
