On Tuesday 21 February 2012 10:47:18 lorn.pot...@nokia.com wrote: > On 21/02/2012, at 8:28 PM, ext David Faure wrote: > > On Tuesday 21 February 2012 10:21:29 lorn.pot...@nokia.com wrote: > >> On 21/02/2012, at 7:36 PM, ext David Faure wrote: > >>> On Tuesday 21 February 2012 06:28:38 wolfgang.b...@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.fa...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development