[Development] QLog ( Work on qDebug and friends)

David Faure david.faure at kdab.com
Tue Feb 21 11:55:05 CET 2012


On Tuesday 21 February 2012 10:47:18 lorn.potter at nokia.com wrote:
> On 21/02/2012, at 8:28 PM, ext David Faure wrote:
> > On Tuesday 21 February 2012 10:21:29 lorn.potter at nokia.com wrote:
> >> On 21/02/2012, at 7:36 PM, ext David Faure wrote:
> >>> On Tuesday 21 February 2012 06:28:38 wolfgang.beck at nokia.com wrote:
> >>>> I'm preferring having QLog active only if a config file is there.
> >>>> It doesn't make sense to me at all having an environment variable that
> >>>> can
> >>>> activate QLog but not config file to activate the categories. As long
> >>>> there
> >>>> is no config file QLog is disable and uses less performance as possible
> >>>> but
> >>>> still having the feature that you can activate it without recompiling
> >>>> the
> >>>> code.
> >>> 
> >>> Why? IMHO things should go to stderr by default. So it makes perfect
> >>> sense
> >>> to see the output, even if one didn't configure output files in a config
> >>> file.
> >> 
> >> The whole idea is to have noop by default. Nothing. Ziltch. Not even std
> >> err. Use qWarning if you want or need that. That's what it's for. If you
> >> need this, only when you do a magical incantation, such as a config file
> >> or
> >> env var, will it produce any output.
> > 
> > I agree.
> > However my point was: once turned on, it could just go to stderr, and not
> > require configuration of an output file.
> 
> Not all systems even have easy stderr output *cough windows*. How are you
> going to retrieve that from an app installed in a sandbox on a clients
> system, when there is no access to a terminal ouput? If you want stderr,
> use qDebug or friends. 

You keep assuming that the developer is working on ONE application, and has 
full control over everything. This isn't how it works, in particular in KDE 
and other opensource Qt apps.
The developer uses qDebug or qLog because that suits him/her, the user ends up 
on a completely different OS, with different needs....

If there is no access to terminal output (well there's always DebugView.exe 
too...), then the user can set up files, this doesn't change anything compared 
to your initial idea.

> How are you going to configure what categories are
> being transmitted without a config file? A string list in an env var?

Some logging frameworks actually do that, I think. (libACE, iirc?)

But OK, I'm withdrawing the whole point - a GUI will do the job just fine, as 
long as the qLog config file *does* allow the output for a given to go to 
stderr, not only to files.

> Who said anything about editing by hand? Simply have them install a
> preconfigured config file you give them. 

Which still requires finding out where the config file must go, on the user's 
system. But OK, no better solution anyway, and the GUI app can find out 
automatically.

> Heck you can even do that at first
> install, so there is a log file, just in case.

Again, with "first install" you assume pre-built binaries and an installer.
Not the case when you download the sources for a random Qt application from 
sourceforge, or when you "apt-get install" or equivalent.
I keep seeing this mindset of "one big commercial application" on this list, 
but Qt developers have to realize that there's also the opensource application 
use case, as well as the "Qt-based framework" use case (where changing the 
defaults for logging, or installing config files, is definitely not wanted).

-- 
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 mailing list