Qt-contributors-summit-2014-QtCS2014 QtLoggingProfiling: Difference between revisions
No edit summary |
m (Categorize) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Cleanup | reason=Auto-imported from ExpressionEngine.}} | |||
[[Category:QtCS2014]] | |||
Additional severity/type levels | Additional severity/type levels | ||
There should be another level, e.g. QtInfoMsg, between QtDebugMsg and QtWarningMsg. Adding another enum will break sources, but | There should be another level, e.g. QtInfoMsg, between QtDebugMsg and QtWarningMsg. Adding another enum will break sources, but that's intentional. | ||
QT_FATAL_WARNINGS | QT_FATAL_WARNINGS | ||
The | The "hammer" QT_FATAL_WARNINGS somewhat goes against the idea of categorized logging. It should be possible to make warnings fatal per category, to be able to e.g. make only Qt warnings fatal. | ||
Another possiblity would be to not use QtWarningMsg in Qt, but QtSystemMsg, or even a new QtApiMisuseMsg … | Another possiblity would be to not use QtWarningMsg in Qt, but QtSystemMsg, or even a new QtApiMisuseMsg … | ||
| Line 11: | Line 13: | ||
Debugging/Inspector Protocol | Debugging/Inspector Protocol | ||
GammaRay uses a network port too to inspect applications, like the QtQml debugger infrastructure does. There seems to be room for unification here … GamaRay though | GammaRay uses a network port too to inspect applications, like the QtQml debugger infrastructure does. There seems to be room for unification here … GamaRay though "injects" the networking part by LD_PRELOAD though (on all platforms), while QtQuick uses a command line argument (—qmljsdebugger) and Qt plugin. | ||
In general we want to move away from Qt specific command line arguments, so adapting the LD_PRELOAD approach might be better … it also resolves some security issues. But things like attaching later to a running application is more error prone. | In general we want to move away from Qt specific command line arguments, so adapting the LD_PRELOAD approach might be better … it also resolves some security issues. But things like attaching later to a running application is more error prone. | ||
Latest revision as of 17:50, 6 January 2017
| This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean. |
Additional severity/type levels
There should be another level, e.g. QtInfoMsg, between QtDebugMsg and QtWarningMsg. Adding another enum will break sources, but that's intentional.
QT_FATAL_WARNINGS
The "hammer" QT_FATAL_WARNINGS somewhat goes against the idea of categorized logging. It should be possible to make warnings fatal per category, to be able to e.g. make only Qt warnings fatal.
Another possiblity would be to not use QtWarningMsg in Qt, but QtSystemMsg, or even a new QtApiMisuseMsg …
Debugging/Inspector Protocol
GammaRay uses a network port too to inspect applications, like the QtQml debugger infrastructure does. There seems to be room for unification here … GamaRay though "injects" the networking part by LD_PRELOAD though (on all platforms), while QtQuick uses a command line argument (—qmljsdebugger) and Qt plugin.
In general we want to move away from Qt specific command line arguments, so adapting the LD_PRELOAD approach might be better … it also resolves some security issues. But things like attaching later to a running application is more error prone.