[Development] QLog ( Work on qDebug and friends)

[Francesco R.(vivo)]

In data giovedì 2 febbraio 2012 14:03:03, David Faure ha scritto:
> On Thursday 02 February 2012 14:56:49 Robin Burchell wrote:
> > On Thu, Feb 2, 2012 at 2:22 PM, David Faure <david.faure at kdab.com> wrote:
> > > 1) showing more information (file, line, method, process name and PID)
> > > in the default message handler, probably based on env vars (easy to
> > > add now that QMessageLogContext has the necessary information).
> > 
> > Please don't show *all* of that by default. Having it *available* is
> > useful, but especially for people working on single applications,
> > things like PID in the console output is completely useless spam.
> > Making it *available*? Sure. KDE could have a message handler that did
> > whatever they wanted, without needing kDebug.
> 
> Sure, I didn't mean that this should be on by default.
> 
> But it would be so extremely useful to set an env var at session startup
> and suddenly make sense of .xsession-errors lines like
> "QGridLayoutEngine::addItem: Cell (0, 1) already taken" which don't
> currently tell form which app they come from.

Is it possible to have a short checksum for the debug/log session which could 
be prefixed to all the following line of output?

this way all the redundand stuff like PID, TID, can be outputted only once, at 
debugging start.
Also this make multiple sources output to a common file easily greppable.

IMHO .xsession-errors should die and it's `chattr +i` on my desktops, to avoid 
some crazy application have a crisys and filling the /home partition (has 
happened only twice in ten years but it's disturbing anyway)

and finally has anyone taken a look at systemd "binary logging"? I didn't but 
maybe there is interesting stuf in there.

/me goes back in the dark

> 
> > Another thing to note is that debugging carries a performance penalty.
> > You definitely don't want that compiled in in release builds
> 
> That's already handled by QT_NO_DEBUG_OUTPUT.
> 
> > and you'd still want to avoid debug in performance-critical areas, even
> > if output wasn't switched on.
> 
> Yep, this still has to be done. We have a solution in KDE for that (a quick
> "is debug enabled for this area" method that then disabled everything else
> in this qdebug object if not), but nothing in Qt yet (we need support for
> areas first ;)
> 
> > Everything else in your mail gets a +3 "approved; give this guy a
> > payrise"
> > 
> > :-)
> 
> LOL, thanks, I'll forward this to my boss then :)