[Bug 41199] [patch] Enhance logging system

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41199

--- Comment #3 from Olli Salli <ollisal at gmail.com> 2011-09-26 02:57:16 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > 09:45 < oggis_> so also, this tpDebugCallback proposed would actually lose the
> > KDebug part of the constructed debug object and it'd turn into a bare QDebug
> > instead (however much that matters)
> 
> fyi, KDebug is not a subclass of QDebug. It's another object that is used as a
> C++ syntax trick to pass the __FILE__ and __LINE__ constants to kDebugStream().
> In the end, it returns a QDebug object constructed with the QDebug(QIODevice*)
> constructor, which then redirects everything to the QIODevice.

Ah, I see. In any case, you can't pass these constants from your debug
callback, because all you'd see would be your debug callback's source file and
line number.

> 
> So, redirecting to a file with Daniele's approach would be something like:
> 
> static QIODevice *s_file; //or better, Q/K_GLOBAL_STATIC
> 
> QDebug tpDebugCallback(QtMsgType type) {
>     //possibly redirect to a different file or /dev/null depending on the type
>     return QDebug(s_file);
> }
> 
> int main() {
>    ...
>    s_file = new QFile("/foo/bar");
>    Tp::setDebugCallback(tpDebugCallback);
>    ...
> }
> 
> And it is not limited at all, since you can create a QIODevice subclass and do
> anything (see kdebug.cpp for examples).
> 
> That said, I am not particularly in favor of one approach over the other. I
> think both approaches are similar in terms of possibilities and ease of use.

A particular limitation with returning a QDebug object is that you don't know
when the object will be destroyed, so

1) you can't use the QString overload of the QDebug ctor (when to send the
string forward?)

2) even if you use the QIODevice overload with some QIODevice guaranteedly
outliving the debug object (such as a static object), you'll lose the
boundaries between the debug messages - those being signaled by (Q)Debug object
destruction. Note that some debug messages are legitimately multi-line. This
might or might not be a problem to you, but I'd rather preserve them if anybody
wants to do anything more specific than raw output to console or a file with
them. (Think sending to an event log with timestamps per warning event, for
example).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.