Looking at some code with some qCDebug/qCWarning statement, like qCDebug(SUBLIME) << "Hello"; one in the very command only sees the code-internal identifier and first has to look up the actual category name. Which can be a little time consuming as the declaration can be in any file, so one first has to search for that. It would be a nice speed-up of workflows if one could also see (and filter) the list in kdebugsettings using that identifier. So the .categories file format should be extended to also allow declaring the identifier (or identifiers, in theory people could use different in different parts of the code for the same category name) which typically is (are) used with a given category name. The filtering would then include matching the registered identifiers, as well as shown them in the tooltip perhaps, next to the actual category name.
Git commit ec488f5ea3976fd4aa74377394daa65af373160a by Laurent Montel. Committed on 31/07/2018 at 11:29. Pushed by mlaurent into branch 'master'. Fix Bug 396959 - Adding support for also having the (known to be used) identifier in the database FIXED-IN: 18.12.0 M +2 -2 autotests/CMakeLists.txt M +72 -31 autotests/kdebugsettingutiltest.cpp M +14 -14 autotests/loadcategoriesjobtest.cpp M +15 -2 src/kdeapplicationtreelistwidget.cpp M +1 -0 src/kdeapplicationtreelistwidget.h M +1 -1 src/kdebugsettingsdialog.cpp M +91 -10 src/kdebugsettingsutil.cpp M +1 -0 src/kdebugsettingsutil.h M +2 -2 src/kdeloggingcategory.cpp M +1 -1 src/kdeloggingcategory.h M +5 -3 src/loadcategoriesjob.cpp M +2 -2 src/loggingcategory.cpp M +3 -4 src/loggingcategory.h https://commits.kde.org/kdebugsettings/ec488f5ea3976fd4aa74377394daa65af373160a
Wow, that was quick, thanks :) Do I see correctly from the unit tests that one would note the identifiers by adding them to the end of the line by the pattern "IDENTIFIER [foo;bar]" ? How backward compatible is this notations to older versions of kdebugsettings? Challenge: e.g. with KDevelop (thus not released in sync with "KDE Applications") how can we know whether to install .catagories files with this notation?
(In reply to Friedrich W. H. Kossebau from comment #2) > Wow, that was quick, thanks :) > > Do I see correctly from the unit tests that one would note the identifiers > by adding them to the end of the line by the pattern "IDENTIFIER [foo;bar]" ? yep > > How backward compatible is this notations to older versions of > kdebugsettings? If we use new notation with old kdebugsettings you will see "IDENTIFIER [foo;bar]" in description. For sure it(s not supported. > > Challenge: > e.g. with KDevelop (thus not released in sync with "KDE Applications") how > can we know whether to install .catagories files with this notation?
(In reply to Laurent Montel from comment #3) > (In reply to Friedrich W. H. Kossebau from comment #2) > > How backward compatible is this notations to older versions of > > kdebugsettings? > > If we use new notation with old kdebugsettings you will see "IDENTIFIER > [foo;bar]" in description. > > For sure it(s not supported. > > > > > Challenge: > > e.g. with KDevelop (thus not released in sync with "KDE Applications") how > > can we know whether to install .catagories files with this notation? So one would have to extend the buildsystem to set a flag whether to generate those additional data or not. And decide the default based on what parsing the output of "kdebugsettings -v" for version tag delivers. Any better idea/recommendation?
categories file is not autogenerated. I don't have idea how to make support in old kdebugsettings version.