[Development] Work on qDebug and friends

[kai.koehne at nokia.com]

> -----Original Message-----
> From: Rose Todd (Nokia-M/Alpharetta)
> Sent: Tuesday, January 24, 2012 5:26 PM
> To: Koehne Kai (Nokia-MP/Berlin); development at qt-project.org
> Subject: RE: Work on qDebug and friends
> 
> [...]
> The "additional things we need" question is pretty subjective, but there are
> probably quite a few things that would be "nice to have".  

Well, I was mainly after things we have to do right now in Qt Core (especially BC breaking changes).

> I usually just copy
> all my logging/tracing/profiling macros around from project to project.  There
> are certain things that you pretty much always need in any non-trivial app:
> 
> - capture log stream and write to file (and manage log file sizes and rotation
> strategy)
> - add current time and current thread id to each log message

Agreed, but we can do this in later on / in a new module.

> - an easy and consistent way to compile out expensive verbose debugging
> code (not just the qDebug() call, but also the code that computes the
> arguments that are passed)

Well, there's the QT_NO_DEBUG_OUPUT, QT_NO_WARNING_OUTPUT defines that you can use also in user code.

> - macros similar to qDebug but that are used to provide simple profiling
> (timing of function/code-block durations)
> - support for utf8 in the log message

Right now the messages are in whatever encoding your compiler uses ...  So most probably Latin1. Don't know whether there's a use case big enough to support conversions here.

> I would also like to see more effort put into the part of QtCreator that parses
> log messages and displays hyperlinks to source files.  The current regex code
> there needs to be loosened up a bit and be more forgiving as far as where in
> the message the __FILE__:__LINE__ portion is.  This is a really nice feature
> when it works, and one of the best uses of the __FILE__ and __LINE__ info,
> but at the moment it doesn't always work correctly because running your
> app in different contexts (desktop/simulator/on-device) will end up with
> different stuff prepended to your log message before it gets to the app
> output window.

Well, that was actually one of the main reasons I started with this: I'd like to have a more standard way of putting out the type, file, line information so that Qt Creator can parse it properly.

> Most of the above is achievable by writing custom message handlers and
> custom macros.  I guess the question is whether that's good enough or
> whether you want to provide more functionality out-of-the-box.

True. As much as I think a logging framework under the Qt project umbrella would be useful, there'll be also always projects who want to implement their own one. But ideally they should be able to do this on the common infrastructure in Qt Core.

Regards

Kai

PS: I should probably point out that I personally don't intend to come up with a full logging framework any time soon, just because of lack of time :(