On 21/02/2012, at 8:28 PM, ext David Faure wrote: > On Tuesday 21 February 2012 10:21:29 [email protected] wrote: >> On 21/02/2012, at 7:36 PM, ext David Faure wrote: >>> On Tuesday 21 February 2012 06:28:38 [email protected] 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 | [email protected] | 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
