[Development] QLog ( Work on qDebug and friends)

[BRM]

> From: André Somers <andre at familiesomers.nl>
> 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.

+1 agreed.
 
> 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 I was not more clear on this point.

I don't think that the extensible framework I was suggesting should be part of Qt Core.
Rather I think Qt should provide an Add-on module - just like QWidget, QNetwork, etc - that provides that functionality;
where we provide some default outputs for a few well-known used systems and leave the ability for others to extend it.
It should be 100% optional, and like with everyone else be able to pull in the content from qDebug(), et al.

Adding the "AREAS" to qDebug(), et al also enables those extensible frameworks - whether provided by Qt or not - to have more granularity as well.

Ben