[Development] Tracing Qt

Koehne Kai Kai.Koehne at digia.com
Mon Aug 26 16:38:16 CEST 2013



-- 
   Kai Köhne, Senior Software Engineer - Digia, Qt
   Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
   Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
   Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
   Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Blasche Alexander
> Sent: Friday, August 23, 2013 2:00 PM
> To: Robin Burchell; development at qt-project.org
> Cc: Poenitz Andre
> Subject: Re: [Development] Tracing Qt
> 
> Hi Robin,
> 
> I am not sure whether you are aware of
> http://qt.gitorious.org/qtplayground/qlogger
> 
> It is pretty much what you describe. It was even close to a merge into qtcore
> already (only rejected due to feature freeze). It gives you a complete API
> including ways to integrate with qDebug/qWarning, runtime activation, little
> to no overhead when deactivated and there was reasonably broad
> agreement already. Also see:
>
> http://lists.qt-project.org/pipermail/development/2012-
> December/008886.html


I actually started a patch back in January that I just revived:

https://codereview.qt-project.org/#change,44430

There are certainly still rough edges, but IMO we should be able to re-use some of it for a hypothetical tracing solution, too.  The actual data flow will be different from the logging case (you don't want to go through QMessageLogger etc, and don't want to convert everything to a QString in the first place), but the idea that you can activate/deactivate categories at runtime through different means is the same.

Regards

Kai



More information about the Development mailing list