[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