On Monday 13 October 2003 16:09, Nicolas Goutte wrote:
> (In any case there seems to be a great need to clarify this for KDE
> 4.)

Here's a more approachable explanation. 
It's not a question of why not to do it, but more a question of when to 
define a debug area.
1) For a common library - always.
2) For an app.
   a) _Do_ if the app is part of the core KDE distribution - Konqueror, 
KMail. _do_ if your app is part of multidependency module with its own 
libraries and the app itself is separated into many part.
The reasoning behind is very simply :
- developers compile KDE with debugging symbols,
- KDE developers usually compile at least kdelibs, kdebase and kdepim 
modules. But sometimes they also do not care about specific apps from 
those packages, but do debug all the rest. As can be seen the debug 
areas for those basic apps are very useful, because by means of them 
being part of the core distribution they are widely installable during 
each make install in those modules and sometimes you simply want to 
disable them (and NO, if compiled with debugging symbols the debugging 
output is NOT off by default, it's on unless overwritten with 
kdebugrc). The debug areas are also useful in huge applications with 
multiple parts - KOffice. Where I might not care at all about kword 
(formatting) but depend with my life on kword (tables). 
  b) _do NOT_ if your app is self contained, not in the core KDE 
distribution or is not composed of multiple parts. This is the case for 
viki. For amarok multiple parts have been defined, but I question the 
need for them, because the app is far from being so huge that the 
output couldn't be controlled. 
The bottom line is that the generic debug area for applications like 
viki is completely enough and it shouldn't be in the kdebug.areas. You 
can redirect the generic (0) output just like you'd do with a reserved 
debug area. You shouldn't worry that you'll redirect other output, 
because libraries do use predefined areas, so when debugging one app - 
that app will be the only one producing the generic output. 
Hopefully that shed some light.

Zack

-- 
This space for sale
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<