[Development] [Request] Add Info to QDebug

Koehne Kai Kai.Koehne at digia.com
Thu Jan 2 14:44:01 CET 2014


Sorry, I'm late to the party (I have been moving house, and still waiting for have been without internet...)

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Andreas Aardal Hanssen
> Sent: Tuesday, December 24, 2013 1:38 AM
> To: development at qt-project.org
> Subject: Re: [Development] [Request] Add Info to QDebug
> 
> On 23 Dec 2013, at 21:39, Kurt Pattyn <pattyn.kurt at gmail.com> wrote:
> 
> 	On 23 Dec 2013, at 17:38, development-request at qt-project.org
> wrote:
> 
> 		From: Andreas Aardal Hanssen <andreas at hanssen.name>
> 
> 		Subject: Re: [Development] [Request] Add Info to QDebug
> 
> 		Date: 23 Dec 2013 15:17:06 GMT+1
> 
> 		To: development at qt-project.org
> 		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





More information about the Development mailing list