add logging intention/types
From Matt Foster:
A problem with logging is that the log is global - that is, all logged information is dumped to the same file. For example, if a log includes performance information and network traffic information, the performance start/stop events could be lost int the network traffic output.
Adding a context to logging that is as simple as a definable integer list would allow logging to be turned on at a more granular level.
#define kPerformanceLogging 1
#define kReportsLogging 2
QsLogging::Logger& logger = QsLogging::Logger::instance();
logger.setLoggingLevel(QsLogging::TraceLevel);
logger.addType(kPerformanceLogging);
logger.addType(kReportsLogging);
The just uploaded files implement this. E.g. QsLogging::Logger& logger = QsLogging::Logger::instance(); logger.addType(1); logger.addType(2);
QLOG_INFOT(3) << "------------------------------------------------------------------------------";
QLOG_INFO() << "------------------------------------------------------------------------------";
QLOG_INFO() << "Program started: " << a.applicationName() << ", " << a.versionString();
QLOG_INFOT(1) << "Built with Qt" << QT_VERSION_STR << "running on" << qVersion();
QLOG_INFOT(2) << "Run date and time: " << QDateTime::currentDateTime().toString();
QLOG_INFOT(3) << "------------------------------------------------------------------------------";
ignores type 3 log events.
Categories/Types/Contexts - I'm not sure what the correct word is.
That the category has a name/id is good. The ID for speed, the name for clarity
The category name appearing in the log file would be a nice touch. Maybe print "level, category, timestamp, message", and then the log file is potentially csv (if no commas are in the text) and can then be sorted
The destinations per category are interesting, but I think they are extra and that if none are specified, the default destination is used.
My model for categories being on/off was that all were on unless specific ones were enabled, at which point others were off. But being able to turn one on and off arbitrarily at some code point might be useful for certain logging applications.
As a rule, category types, on/off, csv files and all kinds of logging niceties should not hinder the simple usage case: the default case is that logging is just on. Just getting it into an app is a good first step.
In a similar vein, I think the single instance with abstraction is more approachable. It doesn't preclude multiple loggers. Maybe mutliple loggers is also how you set desitinations per type, too. The default mechanism provides the simple case, but is flexible in its use.
