On Friday 17 February 2012 09:19:04 Lincoln Ramsay wrote: > > The goal: that global_enabled() affects *all* qDebug statements, not only > > those with a category > > Unlike qLog (which defaults to off), qDebug must be on by default or we > break all existing code. This means a "runtime" switch for qDebug would > only serve to turn all qDebugs off.
"Breaking existing code" in terms of "changing the default in Qt5" isn't that big a deal, it's not like people will have to change their code, just to enable a setting. But I can see an interesting point here: with your current solution, qDebug is the one to use for throw-away debug statements added temporarily to a piece of code one is debugging, while qLog(area) is for debug statements that will stay into the committed code, and therefore the first one should be enabled by default (for convenience) and the second one should be disabled by default (for noise reducing reasons). This is a valid point for the different default, I can accept it. > Is this really a useful thing? Qt itself has no qDebug statements but > perhaps other, third party libraries have left them in. In that case, > having a runtime disable option may be warranted. > > Is that what you meant? Yes, end users don't like debug statements polluting their terminals and session log file. With the above reasoning, we could just keep saying "do not use qDebug in committed code" and the problem would be fixed. But in the case where developers don't follow that rule, users will appreciate an off switch :). > > (try to explain to a new developer, the reason > > why the global switch to disable debug output > > There is no "global switch" to "disable debug output" with qLog. What's QLog::instance()->isEnabled() then ? > Please read the code before commenting on the implementation. > http://codereview.qt-project.org/#change,13226 Hey, I reviewed on that change before I even wrote here. But the global switch idea comes from your own email from 10/02, which says: if (!global_enabled() || !category_enabled(cat)) /*NOP*/; else qDebug()" I didn't make up that notion of global_enabled(), it's from you... > >The only reason is "well, I didn't dare to touch qDebug itself"? > > > > I think it's the right time to touch it :-) > > As has already been covered, the C++ language does not let us overload > the qDebug macro with category support and overloading at the function > level results in a potentially large performance hit. Sorry I didn't mean "the qDebug macro/API", but the QDebug implementation. I'd like qDebug() and qLog() to share as much as possible of the implementation. I can drop the idea of the global enabled switch affecting both, for the reason above, but still, QT_MESSAGE_PATTERN should affect both, qInstallMessageHandler should affect both, etc. More generally, sharing the same output subsystem (with the addition of logging to files, but that's downstream from the shared formatting and handler-hook code). -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development