Extended debug

[Philippe Fremy]

	Hi,

>> On Tuesday 14 August 2007 11:50:11 Thomas Zander wrote:
>>> It would be great if after this thread comes up with a good default we can
>>> steal some ideas from log4j and allow people that work on just one or 2
>>> classes to see only their debug like the old stuff did.  I.e. be
>>> configurable in some way.


In my experience, there are a few things very helpful for a log system,
which are either not available or not used very much in KDE:
- use text based area and have an area hierarchy
- dynamically configure the log level for every area easily
- send log to various types of output: files, debug tools, stdout,
socket, ...

Text-based area and dynamic configuration allows the new user to say
something like:
- set log level to error for everything
- set log level to debug for FooStuff and BarStuff
- set log level to warning for FooStuff.AnnoyingLog and
BarStuff.SuperVerboseStuff
- set log level to debug for
BarStuff.SuperVerboseStuff.TheOneThingICareAbout

I think that you get the idea. This has proven to be very powerful in
the projects I have been working on. You can have a "regular" log level
but you can turn annoying stuff off, and tune on interesting stuff.

Using text based log areas has other advantages over int based log areas:
- you never run out of name
- you can easily be sure that you are not stealing somebody else area
- you don't have to go through a mapping to turn things on and off.

Something else: most log system come with level debug, warning, error.
As soon as you start debugging, you use debug a lot and it becomes
cluttered. By default, your app usually logs in debug mode so you see
everything. So when you finish your debugging, you remove your log lines.

By just adding a level "deepdebug", I was able to keep a lot of
interesting logs - although verbose - in the code. The level deepdebug
is never activated by default, so it does not bother anybody, but it is
still available, in combination with area, to see what's going on deeply.

Another thing that I found very useful is the use of a tool to record
log. When I first worked on windows, I was distressed because gui apps
don't have stdout/stderr. Then I discovered OutputDebugString() and
DebugView. DebugView is a nice tool that will catch the stuff sent by
OutputDebugString. Working with DebugView proved to be superior to
konsole+scrollup:
- easy to record your stuff, or to clean the output to start fresh
- you can easily use filters
- you can use filter-based highlighters, to highlight things that are of
special interest

There are a few opensource log packages on sourceforge, mostly inspired
by log4j:

http://log4cpp.sourceforge.net/

http://log4cplus.sourceforge.net/

They seem to be unmaintained, but working. You can probably find a
thousand more on freshmeat.

The KDE debug output is quite scary for beginners. Things that can make
it easier and more pleasant to use would be very helpful in the
longterm, for both the beginners and the experienced developers.

	cheers,

	Philippe