kdebug.areas

[David Faure]

On Tuesday 28 June 2005 12:39, Nicolas Goutte wrote:
> On Tuesday 28 June 2005 11:57, Stephan Kulow wrote:
> > Am Dienstag 28 Juni 2005 01:07 schrieb Matt Rogers:
> > > I see no problems with this. Generally people just add debug areas at
> > > will. Please commit. :)
> >
> > Yeah, we need to revise this for KDE4. Adding areas shouldn't require a
> > change in kdelibs ;(
> 
> One possibility would be to have multiple files, one per module or per 
> extragear. However I supposed that in this case, the file should better be 
> pre-hashed to speed-up loading (something sort of Gettext's MO files)

As discussed before, I want to implement runtime allocation of areas instead.
Here it is again, in case you have comments on the approach:


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.

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