[Development] QLog ( Work on qDebug and friends)

[lorn.potter at nokia.com]

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.
How are you going to configure what categories are being transmitted without a config file? A string list in an env var?


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