[Development] QLog ( Work on qDebug and friends)

[kai.koehne at nokia.com]

> -----Original Message-----
> From: development-bounces+kai.koehne=nokia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=nokia.com at qt-project.org] On
> Behalf Of Potter Lorn (Nokia-MP/Brisbane)
> Sent: Tuesday, February 21, 2012 11:47 AM
> To: david.faure at kdab.com
> Cc: development at qt-project.org
> Subject: Re: [Development] QLog ( Work on qDebug and friends)
> 
> 
> 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*. 

It has the debugger buffer. Admittedly it has its problems, but it's the standard for IDE's to get output. If you just log to a file, you'll never see your qLog statements in your IDE (unless you hack special support for it to catch the log file or something similar).

> 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? 

You can always specify a file in this case. Logging to a file is sometimes needed, the question is whether it should be the only way to get the data.

> If you want stderr, use
> qDebug or friends.

So I've to tell the customer to get me the qLog file (for qLog warnings), and in addition the console output (for qWarning, qFatal etc)? And then try to match between those to understand what's going on? Or make sure that every qWarning in addition has a qLog ? Doesn't sound appealing to me either ...

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

Why not?

export QT_LOG_CATEGORY="QtCore.IO" isn't that scary, is it? And even if it is more elaborous, you could still have the config file, but not specifying a log file ...

Regards

Kai
> 
> >
> >>> I guess this is a mobile platform vs desktop platform discussion. On
> >>> a mobile platform the logs are only useful if they go to a file,
> >>> while on the desktop the logs are useful also if they go to stderr,
> >>> to get them in a terminal or in the session log file.
> >>
> >> Not really. It's more of not wanting to have any performance hits in
> >> shipping code. Even on embedded systems, developers want and need
> >> console output, and support services might need detailed log file at
> >> times. qlog makes this possible. Nothing stopping anyone from doing a
> >> tail -f my.log
> >
> > But there won't be a "my.log" configured by default, so the user needs
> > to set that up first.
> 
> > I'm aiming at something that is simple to use for the simple case.
> > When a user comes on IRC with a bug and we want to see the output, it
> > should be simple for him/her to get that output. Finding the right
> > config file and editing it by hand isn't exactly simple. Well, OK, a
> > GUI tool can fix that; maybe we can even make that part of qtconfig. That
> would fix the issue nicely, in fact.
> 
> Who said anything about editing by hand? Simply have them install a
> preconfigured config file you give them.
> Heck you can even do that at first install, so there is a log file, just in case.
> 
> :)
> 
> >
> > OK, so objections withdrawn.
> >
> > --
> > 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
> >
> 
> Lorn Potter
> Senior Software Engineer, Core Enablers/QtSensors
> 
> 
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development