Sorry, I'm late to the party (I have been moving house, and still waiting for have been without internet...)
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Andreas Aardal Hanssen > Sent: Tuesday, December 24, 2013 1:38 AM > To: [email protected] > Subject: Re: [Development] [Request] Add Info to QDebug > > On 23 Dec 2013, at 21:39, Kurt Pattyn <[email protected]> wrote: > > On 23 Dec 2013, at 17:38, [email protected] > wrote: > > From: Andreas Aardal Hanssen <[email protected]> > > Subject: Re: [Development] [Request] Add Info to QDebug > > Date: 23 Dec 2013 15:17:06 GMT+1 > > To: [email protected] > FTR, I'm completely -1 for touching QDebug and friends, and > +1 for adding a proper logging framework. QDebug, qWarning, qCritical and > qFatal are for programmers, not administrators who want app log output for > system maintenance. > > I think that QDebug can be a sound foundation for a 'proper' logging > framework. > > > That's as silly as saying the same for printf, or cout. Sorry but I really > disagree > with you. In Java you also don't see system.out.println used in any of the > major > log frameworks there. Well, I'd personally like to make qDebug and friends actually a proper frontend for a logging framework. We're half-way there already: - You can now easily trace the origin (file, line, function) of a message - You can categorize the logging statements (qCXX), and configure the level to be logged individually - We've a flexible default handler that allows formatting of output, and the hooks for a generic output formatter Adding more levels is a natural next step... We actually have it already in QML/JS: console.log console.debug console.info console.warn console.error console.fatal Just that console.log, console.debug, console.info right now all map to QtDebug :) You can argue forever about names, and exact semantics, of each level ... But that misses the point. Some people like to be sparse with logging, some people like to trace every single function entry/exit :) Looking around, about 6 levels seems to be common (log4j, journald, Firebug...) and I fail to see why we shouldn't offer the our users these levels, too. > In our app environment, we have (as many else!) added our > own Log<Info>() << "bar", which formats the log output according to our > system-wide standard. That makes the logs parseable to all our internal tools. > We also override Qt's debug handlers to ensure that any use of qDebug, > warning, critical or fatal ends up properly formatted. I.e. the the debug > handler uses our Log thing. So everbody including KDE has to run their own API, which is spread all over the code base ... Not a compelling argument, if you ask me :) > So, programmers log messages do finally end up in the logs. By using > qSetMessagePattern it is possible to format the log output as well. > > > We have to do that, otherwise they end up as console output, which isn't seen > anywhere. And no, qSetMessagePattern does nothing to solve our problem. > This approach solves the problem the right way - redirecting programmer > noise into a proper logging framework. > > > By only using q(C)Debug(), q(C)Info(), ... there is a single API to do > logging. > By implementing a proper logging backend, Qt could have plugins to > log to (r)syslog(-ng), Windows Event Log, slog2, aso, and then there would be > an almost perfect fit for qDebug(), qInfo(), ... > > > Gah, rather I'd see activity on the project referred to by Thiago. qDebug > isn't a > logging framework, it's just what you use to print debug info to the console. Sorry, I missed that. Which project are you referring to? Regards Kai _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
