Dynamic allocation of debug areas (Re: Removing amarok from kdebug.areas)

[David Faure]

On Friday 04 February 2005 19:56, Waldo Bastian wrote:
> What may be interesting (in general) is to have a slightly more scalable way 
> to specify application-specific debug areas. I can imagine that a third party 
> KDE developer wants to use different kDebug areas in his application but that 
> registering them in the central debug.areas is a bit of a hassle.

Yes; this is on my (kde4) TODO list.
My idea is that some startup code (in libs or apps or modules) could dynamically
register a debug area and get an area number back; those area numbers would
be stored in a globally-accessible object in that lib/app/module. But a singleton
wouldn't be very nice, it would mean the code would have to look like
kdDebug(KMyLib::debugAreas()->uiArea()) << ...
With public ints in a namespace this could be like KMyLibAreas::ui, or even just ui
after a "using namespace...".
This means some header-file code (maybe generated?) like
namespace KMyLibAreas {
   int core;
   int ui;
   int loadsave;
};
and defining those ints in a .cpp file, and initializing them with
  KMyLibAreas::core = KDebugAreas::self()->registerArea( "MyLib core" );
etc.

In order for kdebugdialog to work, each lib/app/module which uses kdebug 
would also have to install a config file in a kdebug-specific directory.
Of course, the user's configuration of enabled/disabled areas would work by 
name (e.g. "MyLib core") instead of by number.

> Reserving a specific "private use" range for that would be a first step.
> (2500 to 2999 ?)
The debug output would then look like "private use 1: <...>". Not very nice :/
A possibility would be to introduce a method to set the label of a given area number,
but this assumes no conflicts (which might happen if both the app and a part or plugin
that it ends up loading, use e.g. 2501).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).