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. André _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
