I had some more thoughts about the Nana/kDebug issue.

I'd like you (everybody) to think of the issue KDE-wide, not
only one-app-wide. Having to compile something with -g simply to get
debug output out of it is nonsense, when you think of it KDE-wide.
Some people hack on (/develop/maintain/...) their app only, and that's
great. But some other people (I fall in this category, and a lot of other
developers as well) fix bugs all over KDE, whenever they see one.
Would those people have to compile all of KDE with -g ? That would be
nonsense.

Even more, apps such as kioslaves are more easily debugged by looking at
their
output than by running then in gdb.

If there is a strong demand from app developers that want to use nana, fine
with me. But I think the core libraries, the kioslaves, and even the rest
(those apps that everybody hack one day or another, such as kdebase), should
rather use an improved kDebug, like the one I suggested.

* Simple API (kDebug(message) for apps, kDebug(area,message) for libs or
apps
  that want to use debug areas)
* Easily turned on/off/syslogged (with a separate program)
* Default config file, so that debug info not relevant to most developers is
turned
  off (just like KRun is turned off manually currently)
* Debug info automatically turned off for releases (not warnings/errors)
(see my initial proposal for more details).

To me, this looks like the best KDE can get in terms of debug output, and
displaying of warnings and errors.

For assertions and other checks, nana brings more, but a new lib for only
that seems overkill to me, and if that's only available with -g, see above.
In that case (requires -g) I think that improving or writing stuff like 
kAssert, kEnsure... would be a better solution. And not very complex to do
at all
(this is not stupidly reinventing the wheel). It's taking some good ideas
out
of something that doesn't have the right approach for KDE (requires -g,
requires gdb...)

Something else: I'd also like kDebug to show filename and line, but that
means
turning it back into a macro. Well, just like nana does, but we moved away
from the KDEBUG macros (one per number of args) for some reason I forgot 
(I thought it was because macros with var args were not supported, but 
according to nana they are...).

I am a bit disappointed that while I try to discuss things, and before
there was any kind of consensus, nana was simply imported into kdelibs. Now
I
look like the guy who want to destroy existing code, whereas I'm not, and
I'm really thinking in terms of what's best for KDE.
Code counts, yes, but deciding before coding counts as well.

Opinions, please !

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems