[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