[Development] QLog ( Work on qDebug and friends)
david.faure at kdab.com
Mon Feb 20 12:42:49 CET 2012
On Monday 20 February 2012 12:25:07 Lincoln Ramsay wrote:
> On 02/17/2012 06:23 PM, ext David Faure wrote:
> > 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 :).
> Ok... I think I'm convinced.
> You can of course always drop these messages from the message handler.
No, users cannot do that ;)
Application developers can, but not library developers nor users.
Especially in the open source world, where libraries and apps are developed by
different people, and the app developers have little control over the code in
the libs they are using. Well, I suspect this happens in commercial setups too
Proper usage of qLog with areas solves the "lib issue", but there's also the
case of using 20 different apps, which use qDebug without an area (that's what
qDebug is for), and users then need to be able to switch it off.
> Turning off qDebugs using the "if (!enabled); else" pattern would make
> these ignored debugs cheaper so it makes sense to do that in the macro.
> Where I'm a bit less clear is how the API for this would look.
> Do you imagine something in the qLog config file? An environment
> variable? A C++ API?
I think "something in the qLog config file" is the best option. It allows to
provide a GUI tool that toggles the configuration, for users.
An env var would be my second favorite, a C++ API is definitely a no since the
goal is to let users toggle it.
David Faure | david.faure at 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
More information about the Development