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. > > 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. 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
