[Development] QLog ( Work on qDebug and friends)

André Somers andre at familiesomers.nl
Thu Feb 2 14:56:07 CET 2012

Op 2-2-2012 13:22, David Faure schreef:
> On Thursday 02 February 2012 12:52:38 =?ISO-8859-1?Q?Andr=E9?= Somers wrote:
>> I think there are plenty of implementations doing this already. Take a
>> look at QxtLogger for instance. It can be used with the output handler
>> just fine, but it also allows more finegrained access with more than
>> four levels. It also supports multiple outputs.
>> I see no need to make all this part of Qt *now*, especially not of core.
>> The very existence of external libraries that integrate with the current
>> structure shows that it is exendable enough.
> Well, Qxt and kdelibs are entire frameworks on top of Qt, but this makes the
> lib code very inconsistent, and not every little app wants to link to a big
> framework, especially for something as small as debug output handling.
> I want to get rid of KDE's kDebug so that there is less difference between "a
> Qt-based library" and "a KDE-based library". The last hurdle for that is:
> 1) showing more information (file, line, method, process name and PID) in the
> default message handler, probably based on env vars (easy to add now that
> QMessageLogContext has the necessary information).
> 2) support for debug areas. QLog's way of defining areas looks very nice, but
> it should be integrated with qDebug, as discussed previously.
> Again, this is about standardizing the debug statements in all qt-based libs,
> it doesn't prevent external loggers handling for the output in customized ways
> in specific apps or frameworks.
I did not mean that there is no need for more information or debug 
area's. I meant that the whole machinery for having different sinks for 
that information (network wat mentioned, rotating file logs, syslogs, 
whatever else) can be left to an external library. I think the 
_gathering_ of all that data (as an extension to qDebug) does belong in 
core, of course, but I think we should not go towards setting up a whole 
complicated output mechamism now.

I think you are focussing on making sure the information is all there to 
use (debug area's and the likes), so I think we agree. I got the feeling 
that BRM (Ben) was more interested in making the output more fancy, and 
that is where I object to putting this into Qt Core, or at least to 
putting that into Qt Core at this moment.

Sorry if my message was not clear before.


More information about the Development mailing list