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