Standardizing Qt logging categories used in KF

Aleix Pol aleixpol at kde.org
Tue Feb 18 12:16:45 GMT 2020


On Mon, Feb 17, 2020 at 7:43 PM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> Hi,
>
> while going through the KF modules to adapt to the new
> ecm_qt_install_logging_categories() macro* to auto-generate KDebugSettings
> .categories (& .renamecategories) files I once more found there is no real
> naming pattern for the logging categories.
> * https://api.kde.org/ecm/module/ECMQtDeclareLoggingCategory.html
>
> Examples:
> org.kde.attica
> org.kde.pim.kcalcore
> kf5.kconfig.core
> kf5.kconfigwidgets
> sonnet.core
> sonnet.plugins.aspell
> kf5.kemoticons.plugin_adium
>
> As a result one cannot "calculate" the name which would be used for a given
> library (or feature), but has to first look that up (or relying on
> kdebugsettings & maintained .categories file). Also am I missing the ability
> from KDebug times where there was the option to control debug output per
> certain feature across libraries/KF modules.
>
> My proposal would be to switch to use these patterns:
>
>     "kf".<module>[.<library>][.<internalfeature>]
>     "kf".<module>.<type-of-plugins>.<plugin>[.<internalfeature>]
>     "kf".<module>.<demon/tool>[.<internalfeature>]
>     "kf".<module>.<publicfeature>[.<othercode>]
>
> So the examples would become:
> kf.attica
> kf.calendarcore
> kf.config.core
> kf.configwidgets
> kf.sonnet.core
> kf.sonnet.clients.aspell
> kf.emoticons.adium
>
> If people agree on such standardization, I would propose to do that renaming
> already now and not only at KF6 time. Given the categories being rather
> undocumented, usually only looked up when needed and kdebugsettings also
> supporting renames, I would think we can improve the situation already now.
> Having clear and known categories also might help once reaching work on KF6,
> when logged debugging might be more used during the Qt6 porting and other 5->6
> work.
>
>
> Please head over to
>         https://phabricator.kde.org/T12716
> for a detailed description and reasoning of the current proposal to the
> problem, and join the discussion over there, so we have a central place to
> collect and track comments/ideas/work.
>
> Cheers
> Friedrich

Standardising the names make sense. I'm not sure if we need a
compatibility path for old names though, people/distrosmust have
configured some things.

Aleix


More information about the Kde-frameworks-devel mailing list