[Development] QLog ( Work on qDebug and friends)
bm_witness at yahoo.com
Thu Feb 2 16:24:21 CET 2012
> 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
>>> 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
>>> The very existence of external libraries that integrate with the
>>> structure shows that it is exendable enough.
>> Well, Qxt and kdelibs are entire frameworks on top of Qt, but this makes
>> 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
>> 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
>> 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 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.
More information about the Development