[Development] More qlogging discussions (was RE: Change I0a9b89c1: QtDebug: Include file, line, function information)

[alex.blasche at nokia.com]

Bringing the discussion back to the mailing list

> -----Original Message-----
> From: ext David Faure [mailto:faure at kde.org]
> On Wednesday 25 January 2012 06:54:09 kai.koehne at nokia.com wrote:
> > > I don't mind to implement the category in a QLogging add-on module.
> >
> > Hi Wolfgang,
> >
> > great to hear! However, don't you think adding categories will require
> some
> > support by qDebug() and friends?
> 
> Yes. I think categories/areas need an argument passed to qDebug, like
> 
> qDebug(area) << "foo";

 +1 from me. 

> On the other hand a separate add-on module with a custom message
> handler for
> configuring what happens to each area (on/off, stderr or file or syslog, etc.) is
> probably a good idea. But that's in addition.
> 
> > might be acceptable too, after all we've been doing fine in the libs without
> > categories so far :)
> 
> For some definition of "fine". IMHO the current situation is very sub-optimal:
> qtbase code cannot have any qDebug() enabled anywhere, since there's no
> way to

David, I think you are still too polite ;). 


> turn on/off per-area, so they are all commented out or ifdef'ed out, so the
> only way to get some debugging out of Qt is to recompile it. Some parts of Qt
> have built their own solution on top, like export QDBUS_DEBUG=1... which
> shows
> that we are not doing so "fine", it would be much better to have a centralized
> solution for this, where e.g. qdbus could have debug statements compiled in,
> but which would be disabled at runtime by default, and the addon could
> provide
> a way (config file, plugin, GUI app, whatever) to enable them without
> recompiling Qt.
>
> A plugin would actually be a cool way of doing it; you install the addon which
> provides a plugin, loaded by qt apps on startup, it installs a different
> default message handler, which has support for areas/categories.
> (while the default handler in QtCore would just ignore that parameter).

My preference goes towards a mere config file. All other solutions have a much higher effort curve. You require toolchains (you may not even have that when support asks you) and the environment may not even support a GUI. Vi will always make it to the device.

I really have a hard time understanding why this has to be in a separate Qt module and not in QtCore .

--
Alex