KDE TechBase - User contributions [en]

User:Tbscope/DebuggingWithSystemtapIndex

2008-11-30T10:18:13Z

Tbscope: Add a short installation text for Systemtap

== What is Systemtap ==

[http://sourceware.org/systemtap/ Systemtap] is a free software tool that helps with gathering all sorts of information on a linux system. It allows you to examine the kernel or user space processes without interrupting them.

You do not need to rebuild your program to add some debugging information. With the use of a simple script you can fully instrument the running kernel or your program to find and fix bugs.

General advantages are that you don't need to do anything special except install Systemtap and compile your programs without stripping debug information. And it's fast. Systemtap uses the scripts you write to create a kernel module that actually hooks into the kernel. This means that you can debug your program at full speed (depending on the system and size of the program of course).

Example:
You've created a new plasmoid but somehow the performance is low. You've looked over the code but can't find the source of the problem. Now, there are a couple of programs that let you examine your plasmoid like valgrind and gdb.

Systemtap however gives you much more control and speed when instrumenting your program. With a simple script of a few lines you can profile your plasmoid and see which files it opens, how long it takes to use these files, how many times a certain function is called, how much memory is used inside a certain function, how long it takes to perform a certain task in a function etc... With all this you can zoom in on the possible problems and fix them.

At the moment Systemtap is a set of commandline tools. But it would be extremely nice to have some sort of a graphical userinterface like Apple's Instruments.

Systemtap can be compared to D-Trace on Unix systems.

Note that the userspace probing in Systemtap is still in development, so it doesn't work 100% correct at the moment.

== Installing Systemtap ==

The most correct way to install Systemtap is to use the packages available from your distribution. The Systemtap [http://sourceware.org/systemtap/wiki wiki] lists a few distributions and how to install Systemtap.

A KDE tool to install and update Systemtap alongside with a few other tools and patches is in the making.

== Systemtap basics ==

todo: How to use Systemtap, the basics.

== Example scripts ==

;[[User:Tbscope/examplesystemtapscripts/usingsysopen|Using sys_open]]
:''This example script uses the kernel sys_open function to see which file is being opened by which process''

User:Tbscope/DebuggingWithSystemtapIndex

2008-11-30T10:08:22Z

Tbscope: Add a little bit of information about Systemtap

== What is Systemtap ==

[http://sourceware.org/systemtap/ Systemtap] is a free software tool that helps with gathering all sorts of information on a linux system. It allows you to examine the kernel or user space processes without interrupting them.

You do not need to rebuild your program to add some debugging information. With the use of a simple script you can fully instrument the running kernel or your program to find and fix bugs.

General advantages are that you don't need to do anything special except install Systemtap and compile your programs without stripping debug information. And it's fast. Systemtap uses the scripts you write to create a kernel module that actually hooks into the kernel. This means that you can debug your program at full speed (depending on the system and size of the program of course).

Example:
You've created a new plasmoid but somehow the performance is low. You've looked over the code but can't find the source of the problem. Now, there are a couple of programs that let you examine your plasmoid like valgrind and gdb.

Systemtap however gives you much more control and speed when instrumenting your program. With a simple script of a few lines you can profile your plasmoid and see which files it opens, how long it takes to use these files, how many times a certain function is called, how much memory is used inside a certain function, how long it takes to perform a certain task in a function etc... With all this you can zoom in on the possible problems and fix them.

At the moment Systemtap is a set of commandline tools. But it would be extremely nice to have some sort of a graphical userinterface like Apple's Instruments.

Systemtap can be compared to D-Trace on Unix systems.

Note that the userspace probing in Systemtap is still in development, so it doesn't work 100% correct at the moment.

== Installing Systemtap ==

todo: Add sections on how to easily install systemtap.

== Systemtap basics ==

todo: How to use Systemtap, the basics.

== Example scripts ==

;[[User:Tbscope/examplesystemtapscripts/usingsysopen|Using sys_open]]
:''This example script uses the kernel sys_open function to see which file is being opened by which process''

User:Tbscope/DebuggingWithSystemtapIndex

2008-11-29T17:01:43Z

Tbscope: Create placeholders for more information

== What is Systemtap ==

todo: put a short and clean description of systemtap here.

== Installing Systemtap ==

todo: Add sections on how to easily install systemtap.

== Systemtap basics ==

todo: How to use Systemtap, the basics.

== Example scripts ==

;[[User:Tbscope/examplesystemtapscripts/usingsysopen|Using sys_open]]
:''This example script uses the kernel sys_open function to see which file is being opened by which process''

User:Tbscope/DebuggingWithSystemtapIndex

2008-11-29T16:57:48Z

Tbscope: Another better layout

== Example scripts ==

;[[User:Tbscope/examplesystemtapscripts/usingsysopen|Using sys_open]]
:''This example script uses the kernel sys_open function to see which file is being opened by which process''

User:Tbscope

2008-11-29T16:55:53Z

Tbscope: Better layout

== Tutorials in construction ==

;[[User:Tbscope/DebuggingWithSystemtapIndex|Debugging with Systemtap]]
:''This tutorial helps you getting started with debugging your programs with systemtap''

User:Tbscope/examplesystemtapscripts/usingsysopen

2008-11-29T16:52:58Z

Tbscope: Show the results correctly 2/2

== Script ==

The following text is the contents of the debug.stp file.

<code>
global starttime

probe begin
{
starttime = gettimeofday_s()
}

probe kernel.function("sys_open").call
{
if(execname()==@1) {
filename = user_string($filename)
printf("[%6d] %s(%d) open %s\n", (gettimeofday_s() - starttime), execname(), pid(), filename)
}
}
</code>

== Results for plasma ==

When the script is run like this:
<code>
sudo stap -v ./debug.stp plasma
</code>

It gives the following results:
<code>
Pass 1: parsed user script and 47 library script(s) in 330usr/0sys/342real ms.
Pass 2: analyzed script: 2 probe(s), 7 function(s), 1 embed(s), 1 global(s) in 220usr/30sys/244real ms.
Pass 3: translated to C into "/tmp/stap34SfoX/stap_8db786e95cd1a11f8070bb0ef7f3ca06_1906.c" in 500usr/190sys/693real ms.
Pass 4: compiled C into "stap_8db786e95cd1a11f8070bb0ef7f3ca06_1906.ko" in 3940usr/480sys/4443real ms.
Pass 5: starting run.
[ 9] plasma(5239) open /etc/fstab
[ 9] plasma(5239) open /etc/mtab
[ 9] plasma(5239) open /proc/mounts
[ 19] plasma(5239) open /etc/mtab
[ 19] plasma(5239) open /proc/mounts
[ 19] plasma(5239) open /etc/fstab
[ 25] plasma(5239) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 29] plasma(5239) open /etc/mtab
[ 29] plasma(5239) open /proc/mounts
[ 39] plasma(5239) open /etc/fstab
[ 39] plasma(5239) open /etc/mtab
[ 39] plasma(5239) open /proc/mounts
[ 49] plasma(5239) open /etc/mtab
[ 49] plasma(5239) open /proc/mounts
[ 59] plasma(5239) open /etc/fstab
[ 59] plasma(5239) open /etc/mtab
[ 59] plasma(5239) open /proc/mounts
^CPass 5: run completed in 0usr/0sys/65800real ms.
</code>

As you can see, plasma opens three specific files every 10 seconds.

== Results for Konsole ==
When the script is run like this:
<code>
sudo stap -v ./debug.stp konsole
</code>

It gives the following results:
<code>
Pass 1: parsed user script and 47 library script(s) in 320usr/20sys/338real ms.
Pass 2: analyzed script: 2 probe(s), 7 function(s), 1 embed(s), 1 global(s) in 210usr/30sys/247real ms.
Pass 3: translated to C into "/tmp/stapKL9fWp/stap_f06923bc6d17872e0d5cfb29c594b1a7_1907.c" in 420usr/250sys/679real ms.
Pass 4: compiled C into "stap_f06923bc6d17872e0d5cfb29c594b1a7_1907.ko" in 3920usr/510sys/4450real ms.
Pass 5: starting run.
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.CE5257
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.gW5257
[ 15] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 39] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 41] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.nu5257
[ 44] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
^CPass 5: run completed in 0usr/10sys/47755real ms.
</code>

User:Tbscope/examplesystemtapscripts/usingsysopen

2008-11-29T16:52:14Z

Tbscope: Show the results correctly 1/2

== Script ==

The following text is the contents of the debug.stp file.

<code>
global starttime

probe begin
{
starttime = gettimeofday_s()
}

probe kernel.function("sys_open").call
{
if(execname()==@1) {
filename = user_string($filename)
printf("[%6d] %s(%d) open %s\n", (gettimeofday_s() - starttime), execname(), pid(), filename)
}
}
</code>

== Results for plasma ==

When the script is run like this:
<code>
sudo stap -v ./debug.stp plasma
</code>

It gives the following results:
<code>
Pass 1: parsed user script and 47 library script(s) in 330usr/0sys/342real ms.
Pass 2: analyzed script: 2 probe(s), 7 function(s), 1 embed(s), 1 global(s) in 220usr/30sys/244real ms.
Pass 3: translated to C into "/tmp/stap34SfoX/stap_8db786e95cd1a11f8070bb0ef7f3ca06_1906.c" in 500usr/190sys/693real ms.
Pass 4: compiled C into "stap_8db786e95cd1a11f8070bb0ef7f3ca06_1906.ko" in 3940usr/480sys/4443real ms.
Pass 5: starting run.
[ 9] plasma(5239) open /etc/fstab
[ 9] plasma(5239) open /etc/mtab
[ 9] plasma(5239) open /proc/mounts
[ 19] plasma(5239) open /etc/mtab
[ 19] plasma(5239) open /proc/mounts
[ 19] plasma(5239) open /etc/fstab
[ 25] plasma(5239) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 29] plasma(5239) open /etc/mtab
[ 29] plasma(5239) open /proc/mounts
[ 39] plasma(5239) open /etc/fstab
[ 39] plasma(5239) open /etc/mtab
[ 39] plasma(5239) open /proc/mounts
[ 49] plasma(5239) open /etc/mtab
[ 49] plasma(5239) open /proc/mounts
[ 59] plasma(5239) open /etc/fstab
[ 59] plasma(5239) open /etc/mtab
[ 59] plasma(5239) open /proc/mounts
^CPass 5: run completed in 0usr/0sys/65800real ms.
</code>

As you can see, plasma opens three specific files every 10 seconds.

== Results for Konsole ==
When the script is run like this:
sudo stap -v ./debug.stp konsole

It gives the following results:
Pass 1: parsed user script and 47 library script(s) in 320usr/20sys/338real ms.
Pass 2: analyzed script: 2 probe(s), 7 function(s), 1 embed(s), 1 global(s) in 210usr/30sys/247real ms.
Pass 3: translated to C into "/tmp/stapKL9fWp/stap_f06923bc6d17872e0d5cfb29c594b1a7_1907.c" in 420usr/250sys/679real ms.
Pass 4: compiled C into "stap_f06923bc6d17872e0d5cfb29c594b1a7_1907.ko" in 3920usr/510sys/4450real ms.
Pass 5: starting run.
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.CE5257
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.gW5257
[ 15] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 39] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 41] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.nu5257
[ 44] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
^CPass 5: run completed in 0usr/10sys/47755real ms.

User:Tbscope/examplesystemtapscripts/usingsysopen

2008-11-29T16:51:16Z

Tbscope: Show the code correctly

== Script ==

The following text is the contents of the debug.stp file.

<code>
global starttime

probe begin
{
starttime = gettimeofday_s()
}

probe kernel.function("sys_open").call
{
if(execname()==@1) {
filename = user_string($filename)
printf("[%6d] %s(%d) open %s\n", (gettimeofday_s() - starttime), execname(), pid(), filename)
}
}
</code>

== Results for plasma ==

When the script is run like this:
sudo stap -v ./debug.stp plasma

It gives the following results:
Pass 1: parsed user script and 47 library script(s) in 330usr/0sys/342real ms.
Pass 2: analyzed script: 2 probe(s), 7 function(s), 1 embed(s), 1 global(s) in 220usr/30sys/244real ms.
Pass 3: translated to C into "/tmp/stap34SfoX/stap_8db786e95cd1a11f8070bb0ef7f3ca06_1906.c" in 500usr/190sys/693real ms.
Pass 4: compiled C into "stap_8db786e95cd1a11f8070bb0ef7f3ca06_1906.ko" in 3940usr/480sys/4443real ms.
Pass 5: starting run.
[ 9] plasma(5239) open /etc/fstab
[ 9] plasma(5239) open /etc/mtab
[ 9] plasma(5239) open /proc/mounts
[ 19] plasma(5239) open /etc/mtab
[ 19] plasma(5239) open /proc/mounts
[ 19] plasma(5239) open /etc/fstab
[ 25] plasma(5239) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 29] plasma(5239) open /etc/mtab
[ 29] plasma(5239) open /proc/mounts
[ 39] plasma(5239) open /etc/fstab
[ 39] plasma(5239) open /etc/mtab
[ 39] plasma(5239) open /proc/mounts
[ 49] plasma(5239) open /etc/mtab
[ 49] plasma(5239) open /proc/mounts
[ 59] plasma(5239) open /etc/fstab
[ 59] plasma(5239) open /etc/mtab
[ 59] plasma(5239) open /proc/mounts
^CPass 5: run completed in 0usr/0sys/65800real ms.

As you can see, plasma opens three specific files every 10 seconds.

== Results for Konsole ==
When the script is run like this:
sudo stap -v ./debug.stp konsole

It gives the following results:
Pass 1: parsed user script and 47 library script(s) in 320usr/20sys/338real ms.
Pass 2: analyzed script: 2 probe(s), 7 function(s), 1 embed(s), 1 global(s) in 210usr/30sys/247real ms.
Pass 3: translated to C into "/tmp/stapKL9fWp/stap_f06923bc6d17872e0d5cfb29c594b1a7_1907.c" in 420usr/250sys/679real ms.
Pass 4: compiled C into "stap_f06923bc6d17872e0d5cfb29c594b1a7_1907.ko" in 3920usr/510sys/4450real ms.
Pass 5: starting run.
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.CE5257
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.gW5257
[ 15] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 39] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 41] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.nu5257
[ 44] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
^CPass 5: run completed in 0usr/10sys/47755real ms.

User:Tbscope/examplesystemtapscripts/usingsysopen

2008-11-29T16:49:22Z

Tbscope: New page: == Script == The following text is the contents of the debug.stp file. global starttime probe begin { starttime = gettimeofday_s() } probe kernel.function("sys_open").call { if...

== Script ==

The following text is the contents of the debug.stp file.

global starttime

probe begin
{
starttime = gettimeofday_s()
}

probe kernel.function("sys_open").call
{
if(execname()==@1) {
filename = user_string($filename)
printf("[%6d] %s(%d) open %s\n", (gettimeofday_s() - starttime), execname(), pid(), filename)
}
}

== Results for plasma ==

When the script is run like this:
sudo stap -v ./debug.stp plasma

It gives the following results:
Pass 1: parsed user script and 47 library script(s) in 330usr/0sys/342real ms.
Pass 2: analyzed script: 2 probe(s), 7 function(s), 1 embed(s), 1 global(s) in 220usr/30sys/244real ms.
Pass 3: translated to C into "/tmp/stap34SfoX/stap_8db786e95cd1a11f8070bb0ef7f3ca06_1906.c" in 500usr/190sys/693real ms.
Pass 4: compiled C into "stap_8db786e95cd1a11f8070bb0ef7f3ca06_1906.ko" in 3940usr/480sys/4443real ms.
Pass 5: starting run.
[ 9] plasma(5239) open /etc/fstab
[ 9] plasma(5239) open /etc/mtab
[ 9] plasma(5239) open /proc/mounts
[ 19] plasma(5239) open /etc/mtab
[ 19] plasma(5239) open /proc/mounts
[ 19] plasma(5239) open /etc/fstab
[ 25] plasma(5239) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 29] plasma(5239) open /etc/mtab
[ 29] plasma(5239) open /proc/mounts
[ 39] plasma(5239) open /etc/fstab
[ 39] plasma(5239) open /etc/mtab
[ 39] plasma(5239) open /proc/mounts
[ 49] plasma(5239) open /etc/mtab
[ 49] plasma(5239) open /proc/mounts
[ 59] plasma(5239) open /etc/fstab
[ 59] plasma(5239) open /etc/mtab
[ 59] plasma(5239) open /proc/mounts
^CPass 5: run completed in 0usr/0sys/65800real ms.

As you can see, plasma opens three specific files every 10 seconds.

== Results for Konsole ==
When the script is run like this:
sudo stap -v ./debug.stp konsole

It gives the following results:
Pass 1: parsed user script and 47 library script(s) in 320usr/20sys/338real ms.
Pass 2: analyzed script: 2 probe(s), 7 function(s), 1 embed(s), 1 global(s) in 210usr/30sys/247real ms.
Pass 3: translated to C into "/tmp/stapKL9fWp/stap_f06923bc6d17872e0d5cfb29c594b1a7_1907.c" in 420usr/250sys/679real ms.
Pass 4: compiled C into "stap_f06923bc6d17872e0d5cfb29c594b1a7_1907.ko" in 3920usr/510sys/4450real ms.
Pass 5: starting run.
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.CE5257
[ 10] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.gW5257
[ 15] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 39] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
[ 41] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.lock.nu5257
[ 44] konsole(5257) open /var/tmp/kdecache-kde4/kpc/kde-icon-cache.updated
^CPass 5: run completed in 0usr/10sys/47755real ms.

User:Tbscope/DebuggingWithSystemtapIndex

2008-11-29T16:46:10Z

Tbscope: Using sys_open with systemtap

== Example scripts ==

[[User:Tbscope/examplesystemtapscripts/usingsysopen]] Using sys_open to see which files are opened by a process.

User:Tbscope/DebuggingWithSystemtapIndex

2008-11-29T16:44:27Z

Tbscope: Add a page with some example systemtap scripts

== Example scripts ==

[[User:Tbscope/examplesystemtapscripts]] List with some examples

User:Tbscope

2008-11-10T08:55:17Z

Tbscope: Fix link

== Tutorials in construction ==

[[User:Tbscope/DebuggingWithSystemtapIndex]] Debugging with Systemtap

User:Tbscope

2008-11-10T08:52:44Z

Tbscope: Update

== Tutorials in construction ==

[[User:Tbscope|DebuggingWithSystemtapIndex]] Debugging with Systemtap

User:Tbscope

2008-11-10T08:44:26Z

Tbscope: Start working on a systemtap debugging tutorial

== Tutorials in construction ==

Debugging with Systemtap

Development/Tutorials/Debugging/Debugging IOSlaves

2006-12-23T18:25:28Z

Tbscope: Add the text from svn to the wiki

This page describes how you can debug an ioslave with gdb.

==How does an io-slave get started?==

Your application request 'klauncher' via DCOP for a slave. If 'klauncher' does
not have an idle slave ready, it will ask kdeinit to start a new one.
kdeinit forks and dlopens the library that contains the io-slave.
Then it calls kdemain() or, if that is not present, main() in the library.

==Attaching gdb to a io-slave==
Due to the above sequence it is rather hard to get an io-slave in your
debugger. But wait there is hope. You can start klauncher in such a way
that slaves for a certain protocol are started in debug mode.

E.g. to start all 'http' slaves in debug mode, you type:

KDE_SLAVE_DEBUG_WAIT=http kdeinit

This will restart 'kdeinit' and 'klauncher'.

When your application now requests a http slave, the slave will be started
by kdeinit, but before it calls kdemain() (cq. main()) it will suspend the
slave by sending it a SIGSTOP signal.

In the terminal from which you started kdeinit you will get the following
message:

kdeinit: Suspending process
kdeinit: 'gdb kdeinit 16779' to debug
kdeinit: 'kill -SIGCONT 16779' to continue

You can now debug your slave by typing (or pasting) 'gdb kdeinit 16779' in
a terminal. If you don't want to debug a slave you can let it continue by
sending it a SIGCONT by typing 'kill -SIGCONT 16779'.

Be aware that slaves will not be killed while they are suspended.

Once you have started gdb, you can set e.g. breakpoints and then resume the
slave by typing 'continue'. The debugger will return immediate with a message
that a SIGSTOP has been received so you will have to type 'continue' a second
time.

==Debugging io-slaves with valgrind==
KLauncher can be told to run certain io-slaves through valgrind. The following
command can be used to let klauncher run all https io-slaves via valgrind:

KDE_SLAVE_VALGRIND=https kdeinit

The valgrind output will appear as the stderr output of the kdeinit process.
The $VALGRIND_OPTS environment variable can be used to pass options to valgrind.
If you want to use a different skin:

KDE_SLAVE_VALGRIND_SKIN=calltree ( for example )

==How to get debug output==
It is useful to redirect the debug output of your particular slave to a file
instead of stderr. E.g. I myself use the following lines in
$KDEDIR/share/config/kdebugrc.

[7113]
InfoOutput=0
InfoFilename=/tmp/http
[7103]
InfoOutput=0
InfoFilename=/tmp/http

This redirects all debug info for areas 7103 and 7113 (as used by kio_http)
to the file /tmp/http.

To get debug information from the SMB slave you can add the following to
kioslaverc:

[SMB]
DebugLevel=100

This will print additional debug info to the stderr of your kdeinit process,
which typically ends up in ~/.X.err or ~/.xsession-errors

Development/FAQs/Debugging FAQ

2006-12-23T18:23:39Z

Tbscope: Prepare to move the text from svn to the wiki

==General==
===How do I avoid Dr Konqi?===
You must set the environment variable KDE_DEBUG (to 1 or whatever you want in fact).

To get Dr Konqi back, unset the KDE_DEBUG environment variable.

Example: 
*To avoid Dr Konqi: 
::<tt>export KDE_DEBUG=1</tt>
*To see Dr Konqi: 
::<tt>unset KDE_DEBUG</tt>

===What is a core file? How do I get a core file?===

A core file is an image of the memory when your application crashed. Using the core file, you can now which variables were set and where your application crashed.

Some distributions disable the generation of core files. To re-enable them, use "ulimit -c unlimited".

Once you have a core file for a crash, you can examine it with gdb appname core . This will open gdb on the core file for the given application. Once at the gdb prompt, the most useful command is "bt" which generates a backtrace of the crash.
For more information about how to use gdb, see this page.

===What tools are available to debug my application?===
kdDebug() calls are a simple but efficient way to debug an application.
gdb, the GNU debugger, is the quickest way to execute step-by-step and investigate variables (prefer the 5.0 version, it is really better than the 4.1.x).
Valgrind
kdbg is a nice graphical frontend to gdb with a KDE GUI. It has support for many Qt types (including QString).
Memory leak tracer : See kdesdk/kmtrace. The README explains it all.
kdcop and dcop allow to browse the dcop interface and to easily make dcop calls.
Check this page and kdesdk, there are a bunch of useful scripts there.

===How do I print a QString in gdb?===
Check out kdesdk, and add this line to your ~/.gdbinit :
source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb
Then in gdb you can do printqstring myqstring to see its contents.
For instance, QString myqstring = QString::fromLatin1("contents"); can be examined using

(gdb) printqstring myqstring
$1 = "content"

See the kde-devel-gdb file for the other macros it defines.

===I have no symbol when I debug an app that uses kpart, what should I do?===
You must stop just after the main to load the debugging symbols of the shared library. After that, you can debug normally.
One can go as far as creating a gdb macro, to stop right after the part was loaded. For kword, by example, I use :

define startkword
break main
run
break 'KoDocument::KoDocument(int, QWidget *, char const *,
QObject *, char const *, bool)' cont

===How do I debug an ioslave?===

See [[/Debugging ioslaves|debugging ioslaves]]

==KDE 3 specific==
===Is there a preferred way to print debug output on stderr?===
Yes, you must use kdDebug():

<code cppqt>
#include <kdebug.h>
kdDebug() << "KMyApp just started" << endl;
</code>

The syntax is much like cout, you can use many native types between the "<<". This will print out a debugging message, which will automatically be turned off at release time (by --disable-debug). In case you want the message to still be there during releases, because it's a warning or an error, use kdWarning() or kdError().

Components and libraries are advised to use a debug area number, as in kdDebug(1234). For this, the number must be registered in kdelibs/kdecore/kdebug.areas. Debug areas make it possible to turn off or on the debug output for specific area numbers, using the "kdebugdialog" program, which is part of kdebase. "kdebugdialog --fullmode" also permits to control where to log debug output. It is usually not necessary to register area numbers for standalone applications, unless it's so complex that you want to divide the output into several areas.

To make it clear: do NOT use qDebug(), this one doesn't get disabled at releases. Also avoid using assert() or kdFatal() which lead to a crash when something goes wrong, never nice for the user. Better detect the error, output a kdWarning or kdError, and recover if possible.

==KDE 4 specific==
===Is there a preferred way to print debug output on stderr?===
Yes, you must use kDebug():

<code cppqt>
#include <kdebug.h>
kDebug() << "KMyApp just started" << endl;
</code>

The syntax is much like cout, you can use many native types between the "<<". This will print out a debugging message, which will automatically be turned off at release time (by --disable-debug). In case you want the message to still be there during releases, because it's a warning or an error, use kWarning() or kError().

Components and libraries are advised to use a debug area number, as in kDebug(1234). For this, the number must be registered in kdelibs/kdecore/kdebug.areas. Debug areas make it possible to turn off or on the debug output for specific area numbers, using the "kdebugdialog" program, which is part of kdebase. "kdebugdialog --fullmode" also permits to control where to log debug output. It is usually not necessary to register area numbers for standalone applications, unless it's so complex that you want to divide the output into several areas.

To make it clear: do NOT use qDebug(), this one doesn't get disabled at releases. Also avoid using assert() or kFatal() which lead to a crash when something goes wrong and that is not a nice experience for the user. Better detect the error, output a kWarning or kError, and recover if possible.

Development/FAQs/Debugging FAQ

2006-12-23T18:12:55Z

Tbscope: There's a difference between kde3 and kde4

==General==
===How do I avoid Dr Konqi?===
You must set the environment variable KDE_DEBUG (to 1 or whatever you want in fact).

To get Dr Konqi back, unset the KDE_DEBUG environment variable.

Example: 
*To avoid Dr Konqi: 
::<tt>export KDE_DEBUG=1</tt>
*To see Dr Konqi: 
::<tt>unset KDE_DEBUG</tt>

===What is a core file? How do I get a core file?===

A core file is an image of the memory when your application crashed. Using the core file, you can now which variables were set and where your application crashed.

Some distributions disable the generation of core files. To re-enable them, use "ulimit -c unlimited".

Once you have a core file for a crash, you can examine it with gdb appname core . This will open gdb on the core file for the given application. Once at the gdb prompt, the most useful command is "bt" which generates a backtrace of the crash.
For more information about how to use gdb, see this page.

===What tools are available to debug my application?===
kdDebug() calls are a simple but efficient way to debug an application.
gdb, the GNU debugger, is the quickest way to execute step-by-step and investigate variables (prefer the 5.0 version, it is really better than the 4.1.x).
Valgrind
kdbg is a nice graphical frontend to gdb with a KDE GUI. It has support for many Qt types (including QString).
Memory leak tracer : See kdesdk/kmtrace. The README explains it all.
kdcop and dcop allow to browse the dcop interface and to easily make dcop calls.
Check this page and kdesdk, there are a bunch of useful scripts there.

===How do I print a QString in gdb?===
Check out kdesdk, and add this line to your ~/.gdbinit :
source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb
Then in gdb you can do printqstring myqstring to see its contents.
For instance, QString myqstring = QString::fromLatin1("contents"); can be examined using

(gdb) printqstring myqstring
$1 = "content"

See the kde-devel-gdb file for the other macros it defines.

===I have no symbol when I debug an app that uses kpart, what should I do?===
You must stop just after the main to load the debugging symbols of the shared library. After that, you can debug normally.
One can go as far as creating a gdb macro, to stop right after the part was loaded. For kword, by example, I use :

define startkword
break main
run
break 'KoDocument::KoDocument(int, QWidget *, char const *,
QObject *, char const *, bool)' cont

===How do I debug an ioslave?===

See kdebase/kioslave/DEBUG.howto

==KDE 3 specific==
===Is there a preferred way to print debug output on stderr?===
Yes, you must use kdDebug():

<code cppqt>
#include <kdebug.h>
kdDebug() << "KMyApp just started" << endl;
</code>

The syntax is much like cout, you can use many native types between the "<<". This will print out a debugging message, which will automatically be turned off at release time (by --disable-debug). In case you want the message to still be there during releases, because it's a warning or an error, use kdWarning() or kdError().

Components and libraries are advised to use a debug area number, as in kdDebug(1234). For this, the number must be registered in kdelibs/kdecore/kdebug.areas. Debug areas make it possible to turn off or on the debug output for specific area numbers, using the "kdebugdialog" program, which is part of kdebase. "kdebugdialog --fullmode" also permits to control where to log debug output. It is usually not necessary to register area numbers for standalone applications, unless it's so complex that you want to divide the output into several areas.

To make it clear: do NOT use qDebug(), this one doesn't get disabled at releases. Also avoid using assert() or kdFatal() which lead to a crash when something goes wrong, never nice for the user. Better detect the error, output a kdWarning or kdError, and recover if possible.

==KDE 4 specific==
===Is there a preferred way to print debug output on stderr?===
Yes, you must use kDebug():

<code cppqt>
#include <kdebug.h>
kDebug() << "KMyApp just started" << endl;
</code>

The syntax is much like cout, you can use many native types between the "<<". This will print out a debugging message, which will automatically be turned off at release time (by --disable-debug). In case you want the message to still be there during releases, because it's a warning or an error, use kWarning() or kError().

Components and libraries are advised to use a debug area number, as in kDebug(1234). For this, the number must be registered in kdelibs/kdecore/kdebug.areas. Debug areas make it possible to turn off or on the debug output for specific area numbers, using the "kdebugdialog" program, which is part of kdebase. "kdebugdialog --fullmode" also permits to control where to log debug output. It is usually not necessary to register area numbers for standalone applications, unless it's so complex that you want to divide the output into several areas.

To make it clear: do NOT use qDebug(), this one doesn't get disabled at releases. Also avoid using assert() or kFatal() which lead to a crash when something goes wrong and that is not a nice experience for the user. Better detect the error, output a kWarning or kError, and recover if possible.

Development/FAQs/General FAQ

2006-12-23T15:18:57Z

Tbscope: Improve layout a little bit

==I want to start this new application. What do you advise?==
We all agree that there are plenty of KDE applications that need to be written. But there are also a lot of existing kde applications that need your help. 
To see the areas where help is needed, check this page. 
Before starting a new application, it's always a good idea to check www.kde-apps.org for existing applications and to ask on the kde-devel@kde.org mailing-list whether someone is already working on a similar project.

==I am a developer, how can I contribute to KDE?==
Check the open jobs from the job list, there is certainly one that you can take. KOffice and KDevelop, despite being very praised, have very few developers, so you might check there. There is no need to be a KDE core-developer to help. KDE is very modular so you can perfectely improve one area without knowing how the whole system works. 
You can also ask on kde-devel if someone needs help on an application.
Use the latest version of KDE and spot things that are needed. A theme generator? A konsole schema editor? Improve a game? There is always a small feature missing. Go and implement it! 
Are you familiar or attracted with a specific field? See if there is a related application that could use your help. Or write one. KDE needs more non-geek oriented applications.

==I am not a developer, how can I help?==
There are plenty of tasks that don't require development skills. Write reviews of applications for the promoting of KDE (see the kde-promo mailing-list), help the documentation team (see i18n.kde.org/doc), help the translations (see i18n.kde.org), help to filter the incoming bugs (see bugs.kde.org).

==Where can I find images of Konqi the dragon?==
The Konqi for some people SDK is at [ftp://ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2 ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2] 
It was posted to artist.kde.org before that site ceased to be updated.

==What is the level required to contribute to KDE? What should I learn? What should I read?==
You need to know C++. Read the Qt tutorials and browse the Qt docs to get familiar with what's available with Qt. Then read the KDE tutorials and browse architecture and documentation. You can also read the KDE Book, it can not harm. But you don't have to be familiar with the whole KDE architecture to become a kde developer. Using kde's technologies is quite easy, so concentrate on what you really need, you can learn the other bits later on.
developer.kde.org and doc.trolltech.com (also in your $QTDIR/doc/html) are invaluable resources, take advantage of them.
Then, browse the source, look for the examples directories, see how the other did code their applications. Reading and writing code is the best way to learn.

==What is SVN? How do I get KDE from SVN?==
See the [anonymous SVN page].

==What should I put in my .subversion/config?==
<code>[miscellany]
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \
*_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \
*.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \
*_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
*.o *.lo *.la #*# .*.rej *.rej</code>
And to make svn diff ignore whitespace, and print function names:
<code>[helpers]
diff-cmd = /usr/local/bin/_svndiff</code>

with the following in <tt>/usr/local/bin/_svndiff</tt>:
<code>#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"</code>

Don't forget to make <tt>/usr/local/bin/_svndiff</tt> executable.

==I want to put my app in KDE:==
There are three requirements:
* your app must compile with the latest version of KDE (SVN trunk).
* your app must be stable.
* your app must be maintained. You will probably get a good deal of bug reports and wishes. People expect you to fix the bugs and implement the wishes that make sense.
See also the next question.

==Is it better to develop inside or outside KDE?==
As core developer Waldo Bastian explains in a copyrighted mail:
----
:Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.
: 
:Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.
: 
:On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.
: 
:You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.
: 
:In general it should be the author of a piece of software that chooses to put his application in SVN. We usualy don't put software in KDE SVN unless the author wishes to do so. The other way around, if the author prefers to work on his application outside SVN then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.
: 
:BUT... by putting your code under and open source license and putting it in KDE SVN you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.
----
It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.

==How do I get SVN access to kde?==
Send a mail to sysadmin (at) kde (dot) org justify why you need SVN access. Make sure to specify your full name and e-mail address, if the From field in your mails doesn't specify them. 

Please include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your SVN and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings. 

You can currently choose between the standard SVN protocol (https using a password) and the svn+ssh using an ssh key. If you choose https, send also an encrypted password (for instance using useradd dummy ; passwd dummy ; grep dummy /etc/passwd /etc/shadow) and see also the tutorial. If you choose svn+ssh, send a public ssh key instead (e.g. ~/.ssh/id_dsa.pub) 

See also How do I create a SSH key? 

If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer... 

Although there is no restrictions on SVN rights, we expect you not to mess up other developers' code without their consent. 
You must also respect the feature freezes of the release schedule (published on developer.kde.org) 
A detailed list of rules you should follow when committing to the KDE SVN repository are listed in the KDE SVN Commit Policy.

==My app is not stable but I would like to have it in KDE==
As a first step, we can put it in playground (== kde-alpha). Develop it there and when it is ready, ask your app to be moved to the appropriate KDE package or the extragear module.

==I don't want to lose my SVN history.==
This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that.

==What is kdebindings?==
It contains Qt/KDE bindings for Java to use Qt/KDE classes with Java, DCOP bindings for C, Java, Perl, Python to use DCOP in those langages and XParts to embed non-KDE apps as a KPart. There are also other bindings for kde which are not maintained by KDE. Check the binding page of developer.kde.org.

==Does the feature freeze apply to kdenonbeta/playground?==
No, kdenonbeta and playground are not a released packages. The same is true for kdereview and extragear: they are not frozen and released. But if you want your app to move to a package, ask for it before the beta-release.

==Can I have a stable and an unstable KDE on the same computer?==
Yes, check the Building 2 Versions documentation.

==How do I know which version of Qt/KDE I am using?==
Launch the KDE Control Center. The splash screen includes Kde version information. 
<tt>kde-config</tt> and all kde programs accept <tt>--version</tt> as argument.

==Qt-copy or Qt from trolltech.com : if one were doing a clean build of trunk, which would be preferable?==
You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. In special, if building qt-copy, pay attention to the apply-patches script.

==How can I checkout a single directory from a SVN module?==
Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir' 
For instance, to get only reaktivate from kdenonbeta: svn co -N /kdenonbeta; svn up admin; svn up reaktivate 
Then compile as usual. 
The same answer applies to the question "How do I get a single language out of kde-i18n?". 
If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.

==How can I get one of the KDE application as a standalone tarball?==
kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.

==How do I close my own bug reports?==
If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happens because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug. 
You can do that from your Subversion commit. To do so, append to your commit message a line like this: 
<tt>BUG: XXXXX</tt> 
Where <tt>XXXXX</tt> is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG. 
Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducable, some without enough information to be corrected, etc. If you can help managing and updating the list of outstanding bug, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.

==How do I create a SSH key?==
SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft. 
Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen. 
When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan. 
If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well. 
For the practical part, the following command can be used to generate a SSH private/public key pair with ssh-keygen -t dsa . This will create a private key as ~/.ssh/id_dsa and 
a public key as ~/.ssh/id_dsa.pub. 
There are times when you may want to use a key of a different name to the default, perhaps to use seperate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example, 
Host svn.kde.org 
IdentityFile ~/.ssh.id_dsa_kde 
In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.

==How can I monitor changes made by others?==
The kde-commits mailinglist carries automatic notifications for all changes made in the KDE SVN repository. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.

Development/FAQs

2006-12-23T14:29:01Z

Tbscope: Finish splitting

Development/FAQs/Debugging FAQ

2006-12-23T14:28:39Z

Tbscope: Add the debugging FAQ

==How do I avoid Dr Konqi?==
You must set the environment variable KDE_DEBUG (to 1 or whatever you want in fact).

==What is a core file? How do I get a core file?==
A core file is an image of the memory when your application crashed. Using the core file, you can now which variables were set and where your application crashed.
Some distributions disable the generation of core files. To re-enable them, use "ulimit -c unlimited".
Once you have a core file for a crash, you can examine it with gdb appname core . This will open gdb on the core file for the given application. Once at the gdb prompt, the most useful command is "bt" which generates a backtrace of the crash.
For more information about how to use gdb, see this page.

==Is there a preferred way to print debug output on stderr?==
Yes, you must use kdDebug():

#include <kdebug.h>
kdDebug() << "KMyApp just started" << endl;
The syntax is much like cout, you can use many native types between the "<<". This will print out a debugging message, which will automatically be turned off at release time (by --disable-debug). In case you want the message to still be there during releases, because it's a warning or an error, use kdWarning() or kdError().
Components and libraries are advised to use a debug area number, as in kdDebug(1234). For this, the number must be registered in kdelibs/kdecore/kdebug.areas. Debug areas make it possible to turn off or on the debug output for specific area numbers, using the "kdebugdialog" program, which is part of kdebase. "kdebugdialog --fullmode" also permits to control where to log debug output. It is usually not necessary to register area numbers for standalone applications, unless it's so complex that you want to divide the output into several areas.
To make it clear: do NOT use qDebug(), this one doesn't get disabled at releases. Also avoid using assert() or kdFatal() which lead to a crash when something goes wrong, never nice for the user. Better detect the error, output a kdWarning or kdError, and recover if possible.

==What tools are available to debug my application?==
kdDebug() calls are a simple but efficient way to debug an application.
gdb, the GNU debugger, is the quickest way to execute step-by-step and investigate variables (prefer the 5.0 version, it is really better than the 4.1.x).
Valgrind
kdbg is a nice graphical frontend to gdb with a KDE GUI. It has support for many Qt types (including QString).
Memory leak tracer : See kdesdk/kmtrace. The README explains it all.
kdcop and dcop allow to browse the dcop interface and to easily make dcop calls.
Check this page and kdesdk, there are a bunch of useful scripts there.

==How do I print a QString in gdb?==
Check out kdesdk, and add this line to your ~/.gdbinit :
source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb
Then in gdb you can do printqstring myqstring to see its contents.
For instance, QString myqstring = QString::fromLatin1("contents"); can be examined using

(gdb) printqstring myqstring
$1 = "content"
See the kde-devel-gdb file for the other macros it defines.

==I have no symbol when I debug an app that uses kpart, what should I do?==
You must stop just after the main to load the debugging symbols of the shared library. After that, you can debug normally.
One can go as far as creating a gdb macro, to stop right after the part was loaded. For kword, by example, I use :
define startkword
break main
run
break 'KoDocument::KoDocument(int, QWidget *, char const *, QObject *, char const *, bool)' cont

==How do I debug an ioslave?==
See kdebase/kioslave/DEBUG.howto

Development/FAQs/Technical FAQ

2006-12-23T14:25:49Z

Tbscope: Add the technical FAQ

==How do I start a new application?==
The easiest way is to use kdesdk/kapptemplate or kdevelop to generate the Makefile.am . Or you can just copy a Makefile.am from another app and install it in a new toplevel directory of existing KDE sources. Or you can start the old way, from scratch, but you'll miss the power of the autoconf/automake framework.

==What is dcop, kpart, kio, kdesktop, kdeinit, ...==
Check developer.kde.org, especially the architecture documents. Check also the kde book.

==Do I really need to use dcop and kpart?==
Well, you are not forced to but it is a _lot_ better. KPart allows powerful code reuse. Dcop allow scriptability and is very powerful. Given how simple it is to use these technology and how widely they are deployed, it is a shame not to use them if you can.

==How do I write a Makefile.am?==
The guide on how to write Makefile.ams is now a separate document, makefile_am_howto.

==How does the Makefile generation works?==
It uses autoconf and automake with another layer by the means of a program named am_edit. But don't try to understand how to use all that. It is quite complex and the strength of KDE is that you don't actually need to understand that stuff, a core-developer already did that for you.
Basically, automake transforms the Makefile.am into a Makefile.in, then am_edit runs and replaces in the Makefile.in all the KDE-specific tags with their real meaning, and configure will create a Makefile out of the Makefile.in

==Why does KDE produce .lo and .la files? Why are the files hidden in a .libs directory? Why is my executable a shellscript?==
Because KDE is using the GNU tool called "libtool". So the question forks into two: "Why use libtool?" and "Why does libtool create .lo and .la files, and shellscripts?".
KDE uses libtool for portability reasons. libtool takes care of the differences between the compilers and especially linkers on various platforms, so that we don't have to bother with that, even when writing shared libraries.
The .lo and .la files are used by libtool to add some information (read them, they are plain text), about object files and libraries. For instance, it remembers which libraries a given library depends upon. Without it, we'd still have to write link lines such as -lkparts -lkio -lkdeui -lkdecore -lqt -lXext -lX11 etc. etc. So you may find it a bit strange that things are "hidden" in .libs, but the gain is huge: complete portability, at no cost for the developers.

==What targets are available to make?==
*all: the default target (the one you get when typing "make").
*clean: removes all the generated files
*distclean: also removes the files generated by Makefile.cvs Not very useful within KDE (see dist for the "dist" concept and svn-clean for a better way to make really clean).
*dist: supposedly for making a tarball out of SVN sources, but not very well supported within KDE. Better use kdesdk/scripts/cvs2pack for that.
*force-reedit: re-run automake and am_edit on the Makefile.am
*install: well, install everything :)
*install-strip: install everything and strips binaries (removes debugging symbols).
*install-exec: only install the binaries and libraries
*install-data: only install the data files
*check: compiles the test programs (i.e. those defined with check_PROGRAMS). It is even possible to actually run some tests during "make check", see kdelibs/arts/tests/Makefile.am

==I have a checkout of SVN, there is no configure and no Makefile?==
Use make -f Makefile.cvs It will run all the Makefile generation steps

==How can I temporarily exclude certain directories from build?==
While hacking a program it might be useful to exclude certain directories from build that would otherwise be recompiled, but don't actually need to be.
Also, if you checked out source code that didn't compile and you don't have the time or knowledge to fix the error you might want to turn off compilation of the directory alltogether.
There are two cases. Toplevel directories, and subdirectories. For toplevel directories you can simply erase them (or not check them out).
If for some reason you don't want to do that, you can also set DO_NOT_COMPILE="someapp" before calling configure, this will make configure skip "someapp". To only compile very few toplevel dirs, instead of using DO_NOT_COMPILE to exclude most of them, you can list in a file named 'inst-apps', at the toplevel, the toplevel subdirs you want to compile.
To turn off compilation of any directory, including subdirectories, you have to modify the Makefile or Makefile.am files. Makefile.am is not recommended because that file is in KDE SVN and you could accidentally commit your changes. So we'll modify the Makefile instead here:
Open the Makefile in the directory immediately above the directory you want to exclude in a text editor and look for a variable SUBDIRS. It will often look somewhat like
SUBDIRS = share core ui . proxy taskmanager taskbar applets extensions data
Just remove the directory that you want to exclude and save your file. A new make will skip the directory you just removed.
Sometimes you'll have to look harder because the SUBDIRS variable consists of a number of other variables:
SUBDIRS = $(COMPILE_FIRST) $(TOPSUBDIRS) $(COMPILE_LAST)
Here you have to find the COMPILE_FIRST, TOPSUBDIRS and COMPILE_LAST variables. One of those contains the dir you want to exclude. Remove the directory where you find it and save the Makefile again.
To undo your changes you can either regenerate the Makefile from scratch or revert to an older backup (you did make one, did you? :-).
To regenerate a Makefile, just make force-reedit.
You can also copy the original line in the file when editing and make it a comment by prefixing a '#' in front of it. Then undoing the change is as easy as making the modified line a comment and removing the comment in the original line.

==What are the various compilation options?==
--enable-debug :
Add debug symbols, disable optimisations and turns logging of kdDebug() on.
--disable-debug:
The opposite of the previous one: enable optimisations and turns kdDebug() logging off.
--enable-final:
Concatenates all .cpp files into one big .all_cpp.cpp file, and compiles it in one go, instead of compiling each .cpp file on its own. This makes the whole compilation much faster, and often leads to better optimised code, but it also requires much more memory. And it often results in compilation errors when headers included by different source files clash one with the other, or when using c static functions with the same name in different source files.
This is a good thing to do at packaging time, but of course not for developers, since a change in one file means recompiling everything.
--disable-fast-perl
By default KDE uses perl instead of sh and sed to convert Makefile.in into Makefile. This is an addition to autoconf done by Michael Matz. You can use this option to disable this but it is a lot slower.

==Which compile option do you recommend?==
If you are a developer, you should definitely compile Qt and KDE with --enable-debug. You will then be able to debug your program even inside Qt and KDE function calls.
If you are just a user, you can still use --enable-debug. KDE will occupy more space on your hard disk but it won't slow down your desktop. The advantage is that you get stack trace when an application crash. If you can reproduce a crashing behaviour, go to bugs.kde.org, check that your bug doesn't exist yet and submit it. It will help us improve kde.
For Qt, the compilation options are explained in qt-copy/README.qt-copy.

==Tips to increase compilation speed?==
See --enable-final above :) . "make final" uses the all-in-one-file trick in the current directory even if --enable-final wasn't used, and "make no-final" does a normal compilation in the current directory even if --enable-final was used.
Include your moc files! Header files declaring a QObject descendant have to be run through moc to produce a .moc file. This .moc file has to be compiled, for which two possibilities exists: compile it separately, or #include it in the C++ file implementing that above mentioned class. The latter is more efficient in term of compilation speed. BTW, kdesdk/scripts/includemocs does this automatically.
Buy more ram, a faster machine and another processor. On a bi-PIII 866 MHz with 1GB of RAM, kde compiles at a decent speed :-)))

==There is a STRIP variable set in the Makefile but it doesn't seem to be used?==
The strip is done at install. To use it, use "make install-strip" instead of "make install".

==What indentation should I use?==
If you are working on an existing application, respect the author's indentation. Else, you can use whatever indentation you like.

==What is the difference between i18n and I18N_NOOP?==
If you do
QString translatedStuff = i18n("foobar");
translatedStuff will contain the translation of "foobar", while for
const char *markedStuff = I18N_NOOP("foobar");
markedStuff will still contain literal "foobar", but translators will know you want "foobar" translated so you can later on do QString translatedStuff = i18n(markedStuff); and get the translation of "foobar", which wouldn't work without that I18N_NOOP.
So, normally you want to just use i18n(), but in cases where you absolutely need to pass something untranslated, but still need to translate it later or in the case that you have something to be translated before the KInstance exists, use I18N_NOOP.

==What is this bug thing with QSpinNumber?==
There is a bug in QSpinNumber, that is not corrected yet. Use KSpinNumber instead, it has almost the same features.

==I get "virtual tables error"?==
This often comes from the moc files not being in sync with the sources, or not linked at all. Check that you are running the right moc. 'which moc' will tell it. Regenerate your moc files (make force-reedit; make clean; make).

==Trying to use dcop, I just added k_dcop to myClassHeader.h file but nothing specific seems to happen?==
Add myClassHeader.kidl to your Makefile.am and run make again.

==Some Makefile.am have a .stub file, what is it for?==
Stubs are not very documented. A stub allow you to view a dcop registered application as an object whose methods are its dcop slots. Usually, applications have an appnameIface.h file that contains all the dcop slots. Add a appnameIface.stub in your Makefile.am and use the object appnameIface. See for example kdebase/khelpcenter that uses a konqueror stub.

==I have added Q_OBJECT to myClassHeader.h but no moc files is generated?==
You need am_edit to reparse your Makefile.am to generate the correct Makefile. If it's the first Q_OBJECT you're using in this directory, you'll need to re-run Makefile.cvs or create_makefile from kdesdk/scripts. Otherwise, you can simply run "make force-reedit".

==To go quicker, I have coded my whole class in a cpp file, how do I get the moc and kidl files generated?==
Hmm, don't do that, if some of the classes use the Q_OBJECT macro. The KDE framework (am_edit) doesn't support this very well. Maybe METASOURCES=file.cpp might work for moc files though.

==I have developed a kpart (or a plugin). I don't want to install it yet because it is not finished but I need that KDE finds it when I request it using KTrader or KLibLoader. How do I do that?==
KDE searches its libraries in $KDEDIR/lib and in the lib directory of all the components of $KDEDIRS (note the additional 'S', this different from $KDEDIR). So, while you are still developing your library and don't want to install it, you can use this trick:
cd to your development directory, the one where your library is built.
Set up KDEDIRS so that it include your development directory: export KDEDIRS=`pwd`:$KDEDIR
Create a pseudo lib directory where KDE should find your component: ln -s .libs lib (all the objects and libraries are built in the .libs directory).
Run kbuildsycoca to inform KDE that it KDEDIRS has changed.
Now, KDE should find your library when using KTrader or KLibLoader.

==How can I install additional KDE stuff when I am not root?==
If want to install your application privately, configure it with another prefix: for $HOME/kdeprefix, use configure --prefix=$HOME/kdeprefix. Then let KDE know about this prefix: set KDEDIRS to $HOME/kdeprefix:$KDEDIR. To make KDE aware of new prefixes, one can also edit /etc/kderc and add
[Directories]
prefixes=/the/new/prefix

but this doesn't answer this specific question ;-)
Make sure to run "kbuildsycoca" after setting the new KDEDIRS.

==My kpart lib is not listed when I request it with KTrader==
The mimetype database must be rebuilt when you install new services (such as applications or parts). In theory this happens by itself (kded is watching those directories), but in doubt, run "kbuildsycoca".
The best way to debug trader-related problems is to use ktradertest: cd kdelibs/kio/tests; make ktradertest, then run ./ktradertest to see how to use it.

==I changed something in kdelibs, installed the new lib, but new KDE apps don't seem to use it?==
The solution is simple: start new apps from a command line, then they will use the new lib.
The reason is that applications started by other KDE applications (kicker, minicli, konqueror, etc.) are started via kdeinit, which loads the libs when KDE starts. So the "old" version of the libs keep being used. But if you want kdeinit to start using the new libs, simply restart it. This is done by typing kdeinit in a terminal.
This is necessary if you can't start things from the command line - e.g. for a kioslave. If you change something in kio, you need to restart kdeinit and kill the running kioslave, so that a new one is started.

==I'm developing both a KPart and a standalone application, how do I avoid duplicated code?==
Apps are often tempted to link to their part because they of course have much functionality in common. However this is wrong for the reasons below.
A lib is something you link to, a module is something you dlopen. You can't dlopen a lib ; you can't link to a module.
A lib has a version number and is installed in $libdir (e.g. $KDEDIR/lib) a module doesn't have a version number (in its name), it's more like a binary (we don't have konqueror-1.14.23 either :), and is installed into kde_moduledir (e.g. $KDEDIR/lib/kde3) (which means it's not in the search path for ld.so, so this breaks on systems without -rpath).
If you didn't understand the above, don't worry. The point is: you should NOT make your application link to your (or any other) KPart, nor any other kind of dlopened module.
The solutions
let the app dlopen the part. This is what KOffice does. However this limits the app to the very limited ReadOnlyPart/ReadWritePart API. Keep in mind that you can't call a non-virtual method whose implementation you don't link to. The solution is to define a ReadWritePart-derived class (like we have in koffice: KoDocument), with new virtual methods. Either this derived class has code (and you need a lib shared by the app and the part, see point 2 below), or an abstract interface (header file only) is enough. You can also use known interfaces to child objects of the part instead of changing the base class of the part itself - this is the solution used by e.g. KParts::BrowserExtension.
define a common library with the common classes and let both the part and the app use it. That library can be noinst_ or lib_, both work. In the first case the compiled object code is duplicated, in the second case a real versioned lib will be installed. The idea here is that the part itself is not available to the app, but instead the part is a very thin wrapper around the same classes as the app uses. Only KParts-specific stuff remains in the part.

==What is the best way to launch another app?==
There is a good answer in the kde2 porting instructions. Check kdelibs/KDE2PORTING.html, also there.

==How do I create and submit a patch to KDE?==
You have spotted a bug and you want to write the code to fix it. Or you want to code a specific feature. Sending a patch is very appreciated by developers. A tutorial is available but here is a description of how you should proceed:
Get the latest KDE using SVN to check that the code you want to write has not been added yet.
Check the bug database to see if your bug is not worked on.
Get in contact with the author. His/her name is in the about box or in the source header. If the project has a mailing-list, browse the archives to see if your bug/feature has not been the subject of any discussion. If you can't find any mailing lists or author, simply write to kde-devel.
Post a message explaining your intentions. It is important to inform the author(s) about what you are planning because somebody might already be working on your feature, or a better design could be proposed by the author, or he could give you some good advice.
Next step is to code your feature. It is usually a good idea to keep an original at hand and to work on a copy. This allow to check the behaviours of both versions of the code. Respect the author's indentation and naming scheme, code carefully, think about side-effects and test everything many times.
Using the latest KDE code, make a diff using either svn diff or a diff -uNp original-dir new-dir. Don't send reversed patch. The first argument of diff should be the old directory and the second the new directory.
Send a mail to the author/mailing-list with your patch as attachment (don't forget to attach it :-) ).
People usually have some remarks on your work and you must work further on your patch to improve it. It is common to see three or four submission before acceptation.
Ok, you have done it, your code has been included in KDE. You are now fully part of the KDE project. Thanx a lot.

==How do I make my application Xinerama and multi-head safe?==
Never make assumptions about the geometry of the "desktop" or the arrangement of the screens. Make use of the following functions from kglobalsettings.h:
static QRect KGlobalSettings::splashScreenDesktopGeometry();
static QRect KGlobalSettings::desktopGeometry(const QPoint& point);
static QRect KGlobalSettings::desktopGeometry(QWidget *w);
Use splashScreenDesktopGeometry() to determine the geometry of the desktop when you want to display an application splash screen. Use desktopGeometry() to determine the geometry of the desktop with respect to a given point on the desktop, or with respect to a given widget. Do not use the Qt class QDesktopWidget to determine these values yourself. The KDE functions take the user's settings into account, something the Qt functions cannot do.
It is ideal to try to avoid using the desktop geometry altogether. Your application will be much more standards compliant if you let the window manager place your windows for you. When this is not possible, you have the aforementioned functions available. Please beware that the geometry that is returned from these functions may not start at (0,0)! Do your math correctly!
One other caution: Both KWin and the NETWM specification have severe difficulties handling struts with Xinerama or "merged" displays. This can result in dead areas on the screen, for instance if kicker does not span a whole edge. There is not much that can be done about this, and you should try to avoid hacks to circumvent this at this time. We hope to find a proper solution for this soon.

==I get an error about KDE not finding UIC plugins, but I know they're installed. What's wrong?==
This is almost certainly an installation problem, not a KDE code problem. A number of problems can lead to this, but most likely you have more than one version of Qt laying around and the configure script is calling a different one than KDE is using.
Another thing that may help is to rebuild and reinstall your kdewidgets.so file, which is located in the kdelibs/kdewidgets directory. Note that if you *do* have multiple versions of Qt, this may compile against the wrong one.
This problem creeps up on various mailing lists occassionally, so looking at the archives on lists.kde.org may be helpful.

==I put some functions in anonymous namespace and someone reverted it and made those functions static, why?==
Symbols defined in a C++ anonymous namespace do NOT have internal linkage. Anonymous namespaces only give an unique name for that translation unit and that is it; they don't change the linkage of the symbol at all. Linkage isn't changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments.

==Can I delete a NULL pointer?==
Yes. Calling delete on a null pointer is a noop in C++. Having "if (ptr) delete ptr;" is redundant. Doing "ptr = 0;" after a delete is a good idea, especially if the delete can be called on it from a different code path.

Development/FAQs/General FAQ

2006-12-23T14:22:11Z

Tbscope: Add the general FAQ

==I want to start this new application. What do you advise?==
We all agree that there are plenty of KDE applications that need to be written. But there are also a lot of existing kde applications that need your help. 
To see the areas where help is needed, check this page. 
Before starting a new application, it's always a good idea to check www.kde-apps.org for existing applications and to ask on the kde-devel@kde.org mailing-list whether someone is already working on a similar project.

==I am a developer, how can I contribute to KDE?==
Check the open jobs from the job list, there is certainly one that you can take. KOffice and KDevelop, despite being very praised, have very few developers, so you might check there. There is no need to be a KDE core-developer to help. KDE is very modular so you can perfectely improve one area without knowing how the whole system works. 
You can also ask on kde-devel if someone needs help on an application.
Use the latest version of KDE and spot things that are needed. A theme generator? A konsole schema editor? Improve a game? There is always a small feature missing. Go and implement it! 
Are you familiar or attracted with a specific field? See if there is a related application that could use your help. Or write one. KDE needs more non-geek oriented applications.

==I am not a developer, how can I help?==
There are plenty of tasks that don't require development skills. Write reviews of applications for the promoting of KDE (see the kde-promo mailing-list), help the documentation team (see i18n.kde.org/doc), help the translations (see i18n.kde.org), help to filter the incoming bugs (see bugs.kde.org).

==Where can I find images of Konqi the dragon?==
The Konqi for some people SDK is at [ftp://ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2 ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2] 
It was posted to artist.kde.org before that site ceased to be updated.

==What is the level required to contribute to KDE? What should I learn? What should I read?==
You need to know C++. Read the Qt tutorials and browse the Qt docs to get familiar with what's available with Qt. Then read the KDE tutorials and browse architecture and documentation. You can also read the KDE Book, it can not harm. But you don't have to be familiar with the whole KDE architecture to become a kde developer. Using kde's technologies is quite easy, so concentrate on what you really need, you can learn the other bits later on.
developer.kde.org and doc.trolltech.com (also in your $QTDIR/doc/html) are invaluable resources, take advantage of them.
Then, browse the source, look for the examples directories, see how the other did code their applications. Reading and writing code is the best way to learn.

==What is SVN? How do I get KDE from SVN?==
See the [anonymous SVN page].

==What should I put in my .subversion/config?==
<code>[miscellany]
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \
*_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \
*.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \
*_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
*.o *.lo *.la #*# .*.rej *.rej</code>
And to make svn diff ignore whitespace, and print function names:
<code>[helpers]
diff-cmd = /usr/local/bin/_svndiff</code>

with the following in <tt>/usr/local/bin/_svndiff</tt>:
<code>#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"</code>

Don't forget to make <tt>/usr/local/bin/_svndiff</tt> executable.

==I want to put my app in KDE:==
There are three requirements:
* your app must compile with the latest version of KDE (SVN trunk).
* your app must be stable.
* your app must be maintained. You will probably get a good deal of bug reports and wishes. People expect you to fix the bugs and implement the wishes that make sense.
See also the next question.

==Is it better to develop inside or outside KDE?==
As core developer Waldo Bastian explains in a copyrighted mail:
----
:Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.
:Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.
:On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.
:You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.
:In general it should be the author of a piece of software that chooses to put his application in SVN. We usualy don't put software in KDE SVN unless the author wishes to do so. The other way around, if the author prefers to work on his application outside SVN then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.
:BUT... by putting your code under and open source license and putting it in KDE SVN you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.
----
It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.

==How do I get SVN access to kde?==
Send a mail to sysadmin (at) kde (dot) org justify why you need SVN access. Make sure to specify your full name and e-mail address, if the From field in your mails doesn't specify them.
Please include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your SVN and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.
You can currently choose between the standard SVN protocol (https using a password) and the svn+ssh using an ssh key. If you choose https, send also an encrypted password (for instance using useradd dummy ; passwd dummy ; grep dummy /etc/passwd /etc/shadow) and see also the tutorial. If you choose svn+ssh, send a public ssh key instead (e.g. ~/.ssh/id_dsa.pub)
See also How do I create a SSH key?
If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...
Although there is no restrictions on SVN rights, we expect you not to mess up other developers' code without their consent.
You must also respect the feature freezes of the release schedule (published on developer.kde.org)
A detailed list of rules you should follow when committing to the KDE SVN repository are listed in the KDE SVN Commit Policy.

==My app is not stable but I would like to have it in KDE==
As a first step, we can put it in playground (== kde-alpha). Develop it there and when it is ready, ask your app to be moved to the appropriate KDE package or the extragear module.

==I don't want to lose my SVN history.==
This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that.

==What is kdebindings?==
It contains Qt/KDE bindings for Java to use Qt/KDE classes with Java, DCOP bindings for C, Java, Perl, Python to use DCOP in those langages and XParts to embed non-KDE apps as a KPart. There are also other bindings for kde which are not maintained by KDE. Check the binding page of developer.kde.org.

==Does the feature freeze apply to kdenonbeta/playground?==
No, kdenonbeta and playground are not a released packages. The same is true for kdereview and extragear: they are not frozen and released. But if you want your app to move to a package, ask for it before the beta-release.

==Can I have a stable and an unstable KDE on the same computer?==
Yes, check the Building 2 Versions documentation.

==How do I know which version of Qt/KDE I am using?==
Launch the KDE Control Center. The splash screen includes Kde version information. 
kde-config and all kde programs accept --version as argument.

==Qt-copy or Qt from trolltech.com : if one were doing a clean build of trunk, which would be preferable?==
You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. In special, if building qt-copy, pay attention to the apply-patches script.

==How can I checkout a single directory from a SVN module?==
Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir'
For instance, to get only reaktivate from kdenonbeta: svn co -N /kdenonbeta; svn up admin; svn up reaktivate
Then compile as usual.
The same answer applies to the question "How do I get a single language out of kde-i18n?".
If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.

==How can I get one of the KDE application as a standalone tarball?==
kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.

==How do I close my own bug reports?==
If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happens because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug.
You can do that from your Subversion commit. To do so, append to your commit message a line like this:
BUG: XXXXX
Where XXXXX is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG.
Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducable, some without enough information to be corrected, etc. If you can help managing and updating the list of outstanding bug, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.

==How do I create a SSH key?==
SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft.
Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen.
When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan.
If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well.
For the practical part, the following command can be used to generate a SSH private/public key pair with ssh-keygen -t dsa . This will create a private key as ~/.ssh/id_dsa and
a public key as ~/.ssh/id_dsa.pub.
There are times when you may want to use a key of a different name to the default, perhaps to use seperate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example,
Host svn.kde.org
IdentityFile ~/.ssh.id_dsa_kde
In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.

==How can I monitor changes made by others?==
The kde-commits mailinglist carries automatic notifications for all changes made in the KDE SVN repository. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.

Development/FAQs

2006-12-23T14:19:05Z

Tbscope: Prepare to split

{{improve}}
;[[/GeneralFAQ|General questions]]
:TODO: Add an explanation for this FAQ.
;[[/TechnicalFAQ|Technical questions]]
:TODO: Add an explanation for this FAQ.
;[[/DebuggingFAQ|Debugging questions]]
:TODO: Add an explanation for this FAQ.
==General questions==
===I want to start this new application. What do you advise?===
We all agree that there are plenty of KDE applications that need to be written. But there are also a lot of existing kde applications that need your help. 
To see the areas where help is needed, check this page. 
Before starting a new application, it's always a good idea to check www.kde-apps.org for existing applications and to ask on the kde-devel@kde.org mailing-list whether someone is already working on a similar project.

===I am a developer, how can I contribute to KDE?===
Check the open jobs from the job list, there is certainly one that you can take. KOffice and KDevelop, despite being very praised, have very few developers, so you might check there. There is no need to be a KDE core-developer to help. KDE is very modular so you can perfectely improve one area without knowing how the whole system works. 
You can also ask on kde-devel if someone needs help on an application.
Use the latest version of KDE and spot things that are needed. A theme generator? A konsole schema editor? Improve a game? There is always a small feature missing. Go and implement it! 
Are you familiar or attracted with a specific field? See if there is a related application that could use your help. Or write one. KDE needs more non-geek oriented applications.

===I am not a developer, how can I help?===
There are plenty of tasks that don't require development skills. Write reviews of applications for the promoting of KDE (see the kde-promo mailing-list), help the documentation team (see i18n.kde.org/doc), help the translations (see i18n.kde.org), help to filter the incoming bugs (see bugs.kde.org).

===Where can I find images of Konqi the dragon?===
The Konqi for some people SDK is at [ftp://ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2 ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2] 
It was posted to artist.kde.org before that site ceased to be updated.

===What is the level required to contribute to KDE? What should I learn? What should I read?===
You need to know C++. Read the Qt tutorials and browse the Qt docs to get familiar with what's available with Qt. Then read the KDE tutorials and browse architecture and documentation. You can also read the KDE Book, it can not harm. But you don't have to be familiar with the whole KDE architecture to become a kde developer. Using kde's technologies is quite easy, so concentrate on what you really need, you can learn the other bits later on.
developer.kde.org and doc.trolltech.com (also in your $QTDIR/doc/html) are invaluable resources, take advantage of them.
Then, browse the source, look for the examples directories, see how the other did code their applications. Reading and writing code is the best way to learn.

===What is SVN? How do I get KDE from SVN?===
See the [anonymous SVN page].

===What should I put in my .subversion/config?===
<code>[miscellany]
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \
*_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \
*.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \
*_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
*.o *.lo *.la #*# .*.rej *.rej</code>
And to make svn diff ignore whitespace, and print function names:
<code>[helpers]
diff-cmd = /usr/local/bin/_svndiff</code>

with the following in <tt>/usr/local/bin/_svndiff</tt>:
<code>#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"</code>

Don't forget to make <tt>/usr/local/bin/_svndiff</tt> executable.

===I want to put my app in KDE:===
There are three requirements:
* your app must compile with the latest version of KDE (SVN trunk).
* your app must be stable.
* your app must be maintained. You will probably get a good deal of bug reports and wishes. People expect you to fix the bugs and implement the wishes that make sense.
See also the next question.

===Is it better to develop inside or outside KDE?===
As core developer Waldo Bastian explains in a copyrighted mail:
----
:Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.
:Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.
:On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.
:You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.
:In general it should be the author of a piece of software that chooses to put his application in SVN. We usualy don't put software in KDE SVN unless the author wishes to do so. The other way around, if the author prefers to work on his application outside SVN then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.
:BUT... by putting your code under and open source license and putting it in KDE SVN you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.
----
It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.

===How do I get SVN access to kde?===
Send a mail to sysadmin (at) kde (dot) org justify why you need SVN access. Make sure to specify your full name and e-mail address, if the From field in your mails doesn't specify them.
Please include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your SVN and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.
You can currently choose between the standard SVN protocol (https using a password) and the svn+ssh using an ssh key. If you choose https, send also an encrypted password (for instance using useradd dummy ; passwd dummy ; grep dummy /etc/passwd /etc/shadow) and see also the tutorial. If you choose svn+ssh, send a public ssh key instead (e.g. ~/.ssh/id_dsa.pub)
See also How do I create a SSH key?
If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...
Although there is no restrictions on SVN rights, we expect you not to mess up other developers' code without their consent.
You must also respect the feature freezes of the release schedule (published on developer.kde.org)
A detailed list of rules you should follow when committing to the KDE SVN repository are listed in the KDE SVN Commit Policy.

===My app is not stable but I would like to have it in KDE===
As a first step, we can put it in playground (== kde-alpha). Develop it there and when it is ready, ask your app to be moved to the appropriate KDE package or the extragear module.

===I don't want to lose my SVN history.===
This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that.

===What is kdebindings?===
It contains Qt/KDE bindings for Java to use Qt/KDE classes with Java, DCOP bindings for C, Java, Perl, Python to use DCOP in those langages and XParts to embed non-KDE apps as a KPart. There are also other bindings for kde which are not maintained by KDE. Check the binding page of developer.kde.org.

===Does the feature freeze apply to kdenonbeta/playground?===
No, kdenonbeta and playground are not a released packages. The same is true for kdereview and extragear: they are not frozen and released. But if you want your app to move to a package, ask for it before the beta-release.

===Can I have a stable and an unstable KDE on the same computer?===
Yes, check the Building 2 Versions documentation.

===How do I know which version of Qt/KDE I am using?===
Launch the KDE Control Center. The splash screen includes Kde version information. 
kde-config and all kde programs accept --version as argument.

===Qt-copy or Qt from trolltech.com : if one were doing a clean build of trunk, which would be preferable?===
You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. In special, if building qt-copy, pay attention to the apply-patches script.

===How can I checkout a single directory from a SVN module?===
Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir'
For instance, to get only reaktivate from kdenonbeta: svn co -N /kdenonbeta; svn up admin; svn up reaktivate
Then compile as usual.
The same answer applies to the question "How do I get a single language out of kde-i18n?".
If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.

===How can I get one of the KDE application as a standalone tarball?===
kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.

===How do I close my own bug reports?===
If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happens because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug.
You can do that from your Subversion commit. To do so, append to your commit message a line like this:
BUG: XXXXX
Where XXXXX is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG.
Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducable, some without enough information to be corrected, etc. If you can help managing and updating the list of outstanding bug, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.

===How do I create a SSH key?===
SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft.
Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen.
When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan.
If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well.
For the practical part, the following command can be used to generate a SSH private/public key pair with ssh-keygen -t dsa . This will create a private key as ~/.ssh/id_dsa and
a public key as ~/.ssh/id_dsa.pub.
There are times when you may want to use a key of a different name to the default, perhaps to use seperate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example,
Host svn.kde.org
IdentityFile ~/.ssh.id_dsa_kde
In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.

===How can I monitor changes made by others?===
The kde-commits mailinglist carries automatic notifications for all changes made in the KDE SVN repository. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.

==Technical questions==
===How do I start a new application?===
The easiest way is to use kdesdk/kapptemplate or kdevelop to generate the Makefile.am . Or you can just copy a Makefile.am from another app and install it in a new toplevel directory of existing KDE sources. Or you can start the old way, from scratch, but you'll miss the power of the autoconf/automake framework.

===What is dcop, kpart, kio, kdesktop, kdeinit, ...===
Check developer.kde.org, especially the architecture documents. Check also the kde book.

===Do I really need to use dcop and kpart?===
Well, you are not forced to but it is a _lot_ better. KPart allows powerful code reuse. Dcop allow scriptability and is very powerful. Given how simple it is to use these technology and how widely they are deployed, it is a shame not to use them if you can.

===How do I write a Makefile.am?===
The guide on how to write Makefile.ams is now a separate document, makefile_am_howto.

===How does the Makefile generation works?===
It uses autoconf and automake with another layer by the means of a program named am_edit. But don't try to understand how to use all that. It is quite complex and the strength of KDE is that you don't actually need to understand that stuff, a core-developer already did that for you.
Basically, automake transforms the Makefile.am into a Makefile.in, then am_edit runs and replaces in the Makefile.in all the KDE-specific tags with their real meaning, and configure will create a Makefile out of the Makefile.in

===Why does KDE produce .lo and .la files? Why are the files hidden in a .libs directory? Why is my executable a shellscript?===
Because KDE is using the GNU tool called "libtool". So the question forks into two: "Why use libtool?" and "Why does libtool create .lo and .la files, and shellscripts?".
KDE uses libtool for portability reasons. libtool takes care of the differences between the compilers and especially linkers on various platforms, so that we don't have to bother with that, even when writing shared libraries.
The .lo and .la files are used by libtool to add some information (read them, they are plain text), about object files and libraries. For instance, it remembers which libraries a given library depends upon. Without it, we'd still have to write link lines such as -lkparts -lkio -lkdeui -lkdecore -lqt -lXext -lX11 etc. etc. So you may find it a bit strange that things are "hidden" in .libs, but the gain is huge: complete portability, at no cost for the developers.

===What targets are available to make?===
*all: the default target (the one you get when typing "make").
*clean: removes all the generated files
*distclean: also removes the files generated by Makefile.cvs Not very useful within KDE (see dist for the "dist" concept and svn-clean for a better way to make really clean).
*dist: supposedly for making a tarball out of SVN sources, but not very well supported within KDE. Better use kdesdk/scripts/cvs2pack for that.
*force-reedit: re-run automake and am_edit on the Makefile.am
*install: well, install everything :)
*install-strip: install everything and strips binaries (removes debugging symbols).
*install-exec: only install the binaries and libraries
*install-data: only install the data files
*check: compiles the test programs (i.e. those defined with check_PROGRAMS). It is even possible to actually run some tests during "make check", see kdelibs/arts/tests/Makefile.am

===I have a checkout of SVN, there is no configure and no Makefile?===
Use make -f Makefile.cvs It will run all the Makefile generation steps

===How can I temporarily exclude certain directories from build?===
While hacking a program it might be useful to exclude certain directories from build that would otherwise be recompiled, but don't actually need to be.
Also, if you checked out source code that didn't compile and you don't have the time or knowledge to fix the error you might want to turn off compilation of the directory alltogether.
There are two cases. Toplevel directories, and subdirectories. For toplevel directories you can simply erase them (or not check them out).
If for some reason you don't want to do that, you can also set DO_NOT_COMPILE="someapp" before calling configure, this will make configure skip "someapp". To only compile very few toplevel dirs, instead of using DO_NOT_COMPILE to exclude most of them, you can list in a file named 'inst-apps', at the toplevel, the toplevel subdirs you want to compile.
To turn off compilation of any directory, including subdirectories, you have to modify the Makefile or Makefile.am files. Makefile.am is not recommended because that file is in KDE SVN and you could accidentally commit your changes. So we'll modify the Makefile instead here:
Open the Makefile in the directory immediately above the directory you want to exclude in a text editor and look for a variable SUBDIRS. It will often look somewhat like
SUBDIRS = share core ui . proxy taskmanager taskbar applets extensions data
Just remove the directory that you want to exclude and save your file. A new make will skip the directory you just removed.
Sometimes you'll have to look harder because the SUBDIRS variable consists of a number of other variables:
SUBDIRS = $(COMPILE_FIRST) $(TOPSUBDIRS) $(COMPILE_LAST)
Here you have to find the COMPILE_FIRST, TOPSUBDIRS and COMPILE_LAST variables. One of those contains the dir you want to exclude. Remove the directory where you find it and save the Makefile again.
To undo your changes you can either regenerate the Makefile from scratch or revert to an older backup (you did make one, did you? :-).
To regenerate a Makefile, just make force-reedit.
You can also copy the original line in the file when editing and make it a comment by prefixing a '#' in front of it. Then undoing the change is as easy as making the modified line a comment and removing the comment in the original line.

===What are the various compilation options?===
--enable-debug :
Add debug symbols, disable optimisations and turns logging of kdDebug() on.
--disable-debug:
The opposite of the previous one: enable optimisations and turns kdDebug() logging off.
--enable-final:
Concatenates all .cpp files into one big .all_cpp.cpp file, and compiles it in one go, instead of compiling each .cpp file on its own. This makes the whole compilation much faster, and often leads to better optimised code, but it also requires much more memory. And it often results in compilation errors when headers included by different source files clash one with the other, or when using c static functions with the same name in different source files.
This is a good thing to do at packaging time, but of course not for developers, since a change in one file means recompiling everything.
--disable-fast-perl
By default KDE uses perl instead of sh and sed to convert Makefile.in into Makefile. This is an addition to autoconf done by Michael Matz. You can use this option to disable this but it is a lot slower.

===Which compile option do you recommend?===
If you are a developer, you should definitely compile Qt and KDE with --enable-debug. You will then be able to debug your program even inside Qt and KDE function calls.
If you are just a user, you can still use --enable-debug. KDE will occupy more space on your hard disk but it won't slow down your desktop. The advantage is that you get stack trace when an application crash. If you can reproduce a crashing behaviour, go to bugs.kde.org, check that your bug doesn't exist yet and submit it. It will help us improve kde.
For Qt, the compilation options are explained in qt-copy/README.qt-copy.

===Tips to increase compilation speed?===
See --enable-final above :) . "make final" uses the all-in-one-file trick in the current directory even if --enable-final wasn't used, and "make no-final" does a normal compilation in the current directory even if --enable-final was used.
Include your moc files! Header files declaring a QObject descendant have to be run through moc to produce a .moc file. This .moc file has to be compiled, for which two possibilities exists: compile it separately, or #include it in the C++ file implementing that above mentioned class. The latter is more efficient in term of compilation speed. BTW, kdesdk/scripts/includemocs does this automatically.
Buy more ram, a faster machine and another processor. On a bi-PIII 866 MHz with 1GB of RAM, kde compiles at a decent speed :-)))

===There is a STRIP variable set in the Makefile but it doesn't seem to be used?===
The strip is done at install. To use it, use "make install-strip" instead of "make install".

===What indentation should I use?===
If you are working on an existing application, respect the author's indentation. Else, you can use whatever indentation you like.

===What is the difference between i18n and I18N_NOOP?===
If you do
QString translatedStuff = i18n("foobar");
translatedStuff will contain the translation of "foobar", while for
const char *markedStuff = I18N_NOOP("foobar");
markedStuff will still contain literal "foobar", but translators will know you want "foobar" translated so you can later on do QString translatedStuff = i18n(markedStuff); and get the translation of "foobar", which wouldn't work without that I18N_NOOP.
So, normally you want to just use i18n(), but in cases where you absolutely need to pass something untranslated, but still need to translate it later or in the case that you have something to be translated before the KInstance exists, use I18N_NOOP.

===What is this bug thing with QSpinNumber?===
There is a bug in QSpinNumber, that is not corrected yet. Use KSpinNumber instead, it has almost the same features.

===I get "virtual tables error"?===
This often comes from the moc files not being in sync with the sources, or not linked at all. Check that you are running the right moc. 'which moc' will tell it. Regenerate your moc files (make force-reedit; make clean; make).

===Trying to use dcop, I just added k_dcop to myClassHeader.h file but nothing specific seems to happen?===
Add myClassHeader.kidl to your Makefile.am and run make again.

===Some Makefile.am have a .stub file, what is it for?===
Stubs are not very documented. A stub allow you to view a dcop registered application as an object whose methods are its dcop slots. Usually, applications have an appnameIface.h file that contains all the dcop slots. Add a appnameIface.stub in your Makefile.am and use the object appnameIface. See for example kdebase/khelpcenter that uses a konqueror stub.

===I have added Q_OBJECT to myClassHeader.h but no moc files is generated?===
You need am_edit to reparse your Makefile.am to generate the correct Makefile. If it's the first Q_OBJECT you're using in this directory, you'll need to re-run Makefile.cvs or create_makefile from kdesdk/scripts. Otherwise, you can simply run "make force-reedit".

===To go quicker, I have coded my whole class in a cpp file, how do I get the moc and kidl files generated?===
Hmm, don't do that, if some of the classes use the Q_OBJECT macro. The KDE framework (am_edit) doesn't support this very well. Maybe METASOURCES=file.cpp might work for moc files though.

===I have developed a kpart (or a plugin). I don't want to install it yet because it is not finished but I need that KDE finds it when I request it using KTrader or KLibLoader. How do I do that?===
KDE searches its libraries in $KDEDIR/lib and in the lib directory of all the components of $KDEDIRS (note the additional 'S', this different from $KDEDIR). So, while you are still developing your library and don't want to install it, you can use this trick:
cd to your development directory, the one where your library is built.
Set up KDEDIRS so that it include your development directory: export KDEDIRS=`pwd`:$KDEDIR
Create a pseudo lib directory where KDE should find your component: ln -s .libs lib (all the objects and libraries are built in the .libs directory).
Run kbuildsycoca to inform KDE that it KDEDIRS has changed.
Now, KDE should find your library when using KTrader or KLibLoader.

===How can I install additional KDE stuff when I am not root?===
If want to install your application privately, configure it with another prefix: for $HOME/kdeprefix, use configure --prefix=$HOME/kdeprefix. Then let KDE know about this prefix: set KDEDIRS to $HOME/kdeprefix:$KDEDIR. To make KDE aware of new prefixes, one can also edit /etc/kderc and add
[Directories]
prefixes=/the/new/prefix

but this doesn't answer this specific question ;-)
Make sure to run "kbuildsycoca" after setting the new KDEDIRS.

===My kpart lib is not listed when I request it with KTrader===
The mimetype database must be rebuilt when you install new services (such as applications or parts). In theory this happens by itself (kded is watching those directories), but in doubt, run "kbuildsycoca".
The best way to debug trader-related problems is to use ktradertest: cd kdelibs/kio/tests; make ktradertest, then run ./ktradertest to see how to use it.

===I changed something in kdelibs, installed the new lib, but new KDE apps don't seem to use it?===
The solution is simple: start new apps from a command line, then they will use the new lib.
The reason is that applications started by other KDE applications (kicker, minicli, konqueror, etc.) are started via kdeinit, which loads the libs when KDE starts. So the "old" version of the libs keep being used. But if you want kdeinit to start using the new libs, simply restart it. This is done by typing kdeinit in a terminal.
This is necessary if you can't start things from the command line - e.g. for a kioslave. If you change something in kio, you need to restart kdeinit and kill the running kioslave, so that a new one is started.

===I'm developing both a KPart and a standalone application, how do I avoid duplicated code?===
Apps are often tempted to link to their part because they of course have much functionality in common. However this is wrong for the reasons below.
A lib is something you link to, a module is something you dlopen. You can't dlopen a lib ; you can't link to a module.
A lib has a version number and is installed in $libdir (e.g. $KDEDIR/lib) a module doesn't have a version number (in its name), it's more like a binary (we don't have konqueror-1.14.23 either :), and is installed into kde_moduledir (e.g. $KDEDIR/lib/kde3) (which means it's not in the search path for ld.so, so this breaks on systems without -rpath).
If you didn't understand the above, don't worry. The point is: you should NOT make your application link to your (or any other) KPart, nor any other kind of dlopened module.
The solutions
let the app dlopen the part. This is what KOffice does. However this limits the app to the very limited ReadOnlyPart/ReadWritePart API. Keep in mind that you can't call a non-virtual method whose implementation you don't link to. The solution is to define a ReadWritePart-derived class (like we have in koffice: KoDocument), with new virtual methods. Either this derived class has code (and you need a lib shared by the app and the part, see point 2 below), or an abstract interface (header file only) is enough. You can also use known interfaces to child objects of the part instead of changing the base class of the part itself - this is the solution used by e.g. KParts::BrowserExtension.
define a common library with the common classes and let both the part and the app use it. That library can be noinst_ or lib_, both work. In the first case the compiled object code is duplicated, in the second case a real versioned lib will be installed. The idea here is that the part itself is not available to the app, but instead the part is a very thin wrapper around the same classes as the app uses. Only KParts-specific stuff remains in the part.

===What is the best way to launch another app?===
There is a good answer in the kde2 porting instructions. Check kdelibs/KDE2PORTING.html, also there.

===How do I create and submit a patch to KDE?===
You have spotted a bug and you want to write the code to fix it. Or you want to code a specific feature. Sending a patch is very appreciated by developers. A tutorial is available but here is a description of how you should proceed:
Get the latest KDE using SVN to check that the code you want to write has not been added yet.
Check the bug database to see if your bug is not worked on.
Get in contact with the author. His/her name is in the about box or in the source header. If the project has a mailing-list, browse the archives to see if your bug/feature has not been the subject of any discussion. If you can't find any mailing lists or author, simply write to kde-devel.
Post a message explaining your intentions. It is important to inform the author(s) about what you are planning because somebody might already be working on your feature, or a better design could be proposed by the author, or he could give you some good advice.
Next step is to code your feature. It is usually a good idea to keep an original at hand and to work on a copy. This allow to check the behaviours of both versions of the code. Respect the author's indentation and naming scheme, code carefully, think about side-effects and test everything many times.
Using the latest KDE code, make a diff using either svn diff or a diff -uNp original-dir new-dir. Don't send reversed patch. The first argument of diff should be the old directory and the second the new directory.
Send a mail to the author/mailing-list with your patch as attachment (don't forget to attach it :-) ).
People usually have some remarks on your work and you must work further on your patch to improve it. It is common to see three or four submission before acceptation.
Ok, you have done it, your code has been included in KDE. You are now fully part of the KDE project. Thanx a lot.

===How do I make my application Xinerama and multi-head safe?===
Never make assumptions about the geometry of the "desktop" or the arrangement of the screens. Make use of the following functions from kglobalsettings.h:
static QRect KGlobalSettings::splashScreenDesktopGeometry();
static QRect KGlobalSettings::desktopGeometry(const QPoint& point);
static QRect KGlobalSettings::desktopGeometry(QWidget *w);
Use splashScreenDesktopGeometry() to determine the geometry of the desktop when you want to display an application splash screen. Use desktopGeometry() to determine the geometry of the desktop with respect to a given point on the desktop, or with respect to a given widget. Do not use the Qt class QDesktopWidget to determine these values yourself. The KDE functions take the user's settings into account, something the Qt functions cannot do.
It is ideal to try to avoid using the desktop geometry altogether. Your application will be much more standards compliant if you let the window manager place your windows for you. When this is not possible, you have the aforementioned functions available. Please beware that the geometry that is returned from these functions may not start at (0,0)! Do your math correctly!
One other caution: Both KWin and the NETWM specification have severe difficulties handling struts with Xinerama or "merged" displays. This can result in dead areas on the screen, for instance if kicker does not span a whole edge. There is not much that can be done about this, and you should try to avoid hacks to circumvent this at this time. We hope to find a proper solution for this soon.

===I get an error about KDE not finding UIC plugins, but I know they're installed. What's wrong?===
This is almost certainly an installation problem, not a KDE code problem. A number of problems can lead to this, but most likely you have more than one version of Qt laying around and the configure script is calling a different one than KDE is using.
Another thing that may help is to rebuild and reinstall your kdewidgets.so file, which is located in the kdelibs/kdewidgets directory. Note that if you *do* have multiple versions of Qt, this may compile against the wrong one.
This problem creeps up on various mailing lists occassionally, so looking at the archives on lists.kde.org may be helpful.

===I put some functions in anonymous namespace and someone reverted it and made those functions static, why?===
Symbols defined in a C++ anonymous namespace do NOT have internal linkage. Anonymous namespaces only give an unique name for that translation unit and that is it; they don't change the linkage of the symbol at all. Linkage isn't changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments.

===Can I delete a NULL pointer?===
Yes. Calling delete on a null pointer is a noop in C++. Having "if (ptr) delete ptr;" is redundant. Doing "ptr = 0;" after a delete is a good idea, especially if the delete can be called on it from a different code path.

==Debugging==
===How do I avoid Dr Konqi?===
You must set the environment variable KDE_DEBUG (to 1 or whatever you want in fact).

===What is a core file? How do I get a core file?===
A core file is an image of the memory when your application crashed. Using the core file, you can now which variables were set and where your application crashed.
Some distributions disable the generation of core files. To re-enable them, use "ulimit -c unlimited".
Once you have a core file for a crash, you can examine it with gdb appname core . This will open gdb on the core file for the given application. Once at the gdb prompt, the most useful command is "bt" which generates a backtrace of the crash.
For more information about how to use gdb, see this page.

===Is there a preferred way to print debug output on stderr?===
Yes, you must use kdDebug():

#include <kdebug.h>
kdDebug() << "KMyApp just started" << endl;
The syntax is much like cout, you can use many native types between the "<<". This will print out a debugging message, which will automatically be turned off at release time (by --disable-debug). In case you want the message to still be there during releases, because it's a warning or an error, use kdWarning() or kdError().
Components and libraries are advised to use a debug area number, as in kdDebug(1234). For this, the number must be registered in kdelibs/kdecore/kdebug.areas. Debug areas make it possible to turn off or on the debug output for specific area numbers, using the "kdebugdialog" program, which is part of kdebase. "kdebugdialog --fullmode" also permits to control where to log debug output. It is usually not necessary to register area numbers for standalone applications, unless it's so complex that you want to divide the output into several areas.
To make it clear: do NOT use qDebug(), this one doesn't get disabled at releases. Also avoid using assert() or kdFatal() which lead to a crash when something goes wrong, never nice for the user. Better detect the error, output a kdWarning or kdError, and recover if possible.

===What tools are available to debug my application?===
kdDebug() calls are a simple but efficient way to debug an application.
gdb, the GNU debugger, is the quickest way to execute step-by-step and investigate variables (prefer the 5.0 version, it is really better than the 4.1.x).
Valgrind
kdbg is a nice graphical frontend to gdb with a KDE GUI. It has support for many Qt types (including QString).
Memory leak tracer : See kdesdk/kmtrace. The README explains it all.
kdcop and dcop allow to browse the dcop interface and to easily make dcop calls.
Check this page and kdesdk, there are a bunch of useful scripts there.

===How do I print a QString in gdb?===
Check out kdesdk, and add this line to your ~/.gdbinit :
source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb
Then in gdb you can do printqstring myqstring to see its contents.
For instance, QString myqstring = QString::fromLatin1("contents"); can be examined using

(gdb) printqstring myqstring
$1 = "content"
See the kde-devel-gdb file for the other macros it defines.

===I have no symbol when I debug an app that uses kpart, what should I do?===
You must stop just after the main to load the debugging symbols of the shared library. After that, you can debug normally.
One can go as far as creating a gdb macro, to stop right after the part was loaded. For kword, by example, I use :
define startkword
break main
run
break 'KoDocument::KoDocument(int, QWidget *, char const *, QObject *, char const *, bool)' cont

===How do I debug an ioslave?===
See kdebase/kioslave/DEBUG.howto

Original question list by Philippe Fremy, answers by David Faure.
Contributions from: Marco Krohn, Malte Starostik, Andreas Pour, Waldo Bastian, Lars Knoll, Triskelios, Eric Sigra, Rolf Dubitzky, Martijn Klingens, Karl-Heinz Zimmer, George Staikos.
Please send additional questions, responses or comments to pfremy at kde dot org

Development/FAQs

2006-12-23T14:10:37Z

Tbscope: Adding the developer FAQ page. Basic without layout and improvements

==General questions==
===I want to start this new application. What do you advise?===
We all agree that there are plenty of KDE applications that need to be written. But there are also a lot of existing kde applications that need your help. 
To see the areas where help is needed, check this page. 
Before starting a new application, it's always a good idea to check www.kde-apps.org for existing applications and to ask on the kde-devel@kde.org mailing-list whether someone is already working on a similar project.

===I am a developer, how can I contribute to KDE?===
Check the open jobs from the job list, there is certainly one that you can take. KOffice and KDevelop, despite being very praised, have very few developers, so you might check there. There is no need to be a KDE core-developer to help. KDE is very modular so you can perfectely improve one area without knowing how the whole system works. 
You can also ask on kde-devel if someone needs help on an application.
Use the latest version of KDE and spot things that are needed. A theme generator? A konsole schema editor? Improve a game? There is always a small feature missing. Go and implement it! 
Are you familiar or attracted with a specific field? See if there is a related application that could use your help. Or write one. KDE needs more non-geek oriented applications.

===I am not a developer, how can I help?===
There are plenty of tasks that don't require development skills. Write reviews of applications for the promoting of KDE (see the kde-promo mailing-list), help the documentation team (see i18n.kde.org/doc), help the translations (see i18n.kde.org), help to filter the incoming bugs (see bugs.kde.org).

===Where can I find images of Konqi the dragon?===
The Konqi for some people SDK is at [ftp://ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2 ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2] 
It was posted to artist.kde.org before that site ceased to be updated.

===What is the level required to contribute to KDE? What should I learn? What should I read?===
You need to know C++. Read the Qt tutorials and browse the Qt docs to get familiar with what's available with Qt. Then read the KDE tutorials and browse architecture and documentation. You can also read the KDE Book, it can not harm. But you don't have to be familiar with the whole KDE architecture to become a kde developer. Using kde's technologies is quite easy, so concentrate on what you really need, you can learn the other bits later on.
developer.kde.org and doc.trolltech.com (also in your $QTDIR/doc/html) are invaluable resources, take advantage of them.
Then, browse the source, look for the examples directories, see how the other did code their applications. Reading and writing code is the best way to learn.

===What is SVN? How do I get KDE from SVN?===
See the [anonymous SVN page].

===What should I put in my .subversion/config?===
<code>[miscellany]
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \
*_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \
*.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \
*_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
*.o *.lo *.la #*# .*.rej *.rej</code>
And to make svn diff ignore whitespace, and print function names:
<code>[helpers]
diff-cmd = /usr/local/bin/_svndiff</code>

with the following in <tt>/usr/local/bin/_svndiff</tt>:
<code>#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"</code>

Don't forget to make <tt>/usr/local/bin/_svndiff</tt> executable.

===I want to put my app in KDE:===
There are three requirements:
* your app must compile with the latest version of KDE (SVN trunk).
* your app must be stable.
* your app must be maintained. You will probably get a good deal of bug reports and wishes. People expect you to fix the bugs and implement the wishes that make sense.
See also the next question.

===Is it better to develop inside or outside KDE?===
As core developer Waldo Bastian explains in a copyrighted mail:
----
:Being part of KDE means that you have to work together with others. Such cooperation brings along advantages but it also brings along responsibilities.
:Some of those advantages are: your code ends up on all distro's, people might fix your bugs, you get free translations and documentation, you get tons of bugreports.
:On the other side there are disadvantages and responsibilities: you will have to communicate with other developers about your work, other people might make changes to your code, you will have to respect release freezes, you get tons of bugreports and people actually expect that you fix them as well (what are they smoking?), people expect you to maintain your code.
:You can't chose for the advantages and ignore the responsibilities that come with it, it's a complete package, it's both or nothing.
:In general it should be the author of a piece of software that chooses to put his application in SVN. We usualy don't put software in KDE SVN unless the author wishes to do so. The other way around, if the author prefers to work on his application outside SVN then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.
:BUT... by putting your code under and open source license and putting it in KDE SVN you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.
----
It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.

===How do I get SVN access to kde?===
Send a mail to sysadmin (at) kde (dot) org justify why you need SVN access. Make sure to specify your full name and e-mail address, if the From field in your mails doesn't specify them.
Please include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your SVN and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.
You can currently choose between the standard SVN protocol (https using a password) and the svn+ssh using an ssh key. If you choose https, send also an encrypted password (for instance using useradd dummy ; passwd dummy ; grep dummy /etc/passwd /etc/shadow) and see also the tutorial. If you choose svn+ssh, send a public ssh key instead (e.g. ~/.ssh/id_dsa.pub)
See also How do I create a SSH key?
If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...
Although there is no restrictions on SVN rights, we expect you not to mess up other developers' code without their consent.
You must also respect the feature freezes of the release schedule (published on developer.kde.org)
A detailed list of rules you should follow when committing to the KDE SVN repository are listed in the KDE SVN Commit Policy.

===My app is not stable but I would like to have it in KDE===
As a first step, we can put it in playground (== kde-alpha). Develop it there and when it is ready, ask your app to be moved to the appropriate KDE package or the extragear module.

===I don't want to lose my SVN history.===
This is no longer possible with Subversion. Maybe in the future, if the server is upgraded and allows that.

===What is kdebindings?===
It contains Qt/KDE bindings for Java to use Qt/KDE classes with Java, DCOP bindings for C, Java, Perl, Python to use DCOP in those langages and XParts to embed non-KDE apps as a KPart. There are also other bindings for kde which are not maintained by KDE. Check the binding page of developer.kde.org.

===Does the feature freeze apply to kdenonbeta/playground?===
No, kdenonbeta and playground are not a released packages. The same is true for kdereview and extragear: they are not frozen and released. But if you want your app to move to a package, ask for it before the beta-release.

===Can I have a stable and an unstable KDE on the same computer?===
Yes, check the Building 2 Versions documentation.

===How do I know which version of Qt/KDE I am using?===
Launch the KDE Control Center. The splash screen includes Kde version information. 
kde-config and all kde programs accept --version as argument.

===Qt-copy or Qt from trolltech.com : if one were doing a clean build of trunk, which would be preferable?===
You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. In special, if building qt-copy, pay attention to the apply-patches script.

===How can I checkout a single directory from a SVN module?===
Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir'
For instance, to get only reaktivate from kdenonbeta: svn co -N /kdenonbeta; svn up admin; svn up reaktivate
Then compile as usual.
The same answer applies to the question "How do I get a single language out of kde-i18n?".
If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.

===How can I get one of the KDE application as a standalone tarball?===
kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.

===How do I close my own bug reports?===
If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happens because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug.
You can do that from your Subversion commit. To do so, append to your commit message a line like this:
BUG: XXXXX
Where XXXXX is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG.
Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducable, some without enough information to be corrected, etc. If you can help managing and updating the list of outstanding bug, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.

===How do I create a SSH key?===
SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft.
Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen.
When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan.
If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well.
For the practical part, the following command can be used to generate a SSH private/public key pair with ssh-keygen -t dsa . This will create a private key as ~/.ssh/id_dsa and
a public key as ~/.ssh/id_dsa.pub.
There are times when you may want to use a key of a different name to the default, perhaps to use seperate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example,
Host svn.kde.org
IdentityFile ~/.ssh.id_dsa_kde
In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.

===How can I monitor changes made by others?===
The kde-commits mailinglist carries automatic notifications for all changes made in the KDE SVN repository. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.

==Technical questions==
===How do I start a new application?===
The easiest way is to use kdesdk/kapptemplate or kdevelop to generate the Makefile.am . Or you can just copy a Makefile.am from another app and install it in a new toplevel directory of existing KDE sources. Or you can start the old way, from scratch, but you'll miss the power of the autoconf/automake framework.

===What is dcop, kpart, kio, kdesktop, kdeinit, ...===
Check developer.kde.org, especially the architecture documents. Check also the kde book.

===Do I really need to use dcop and kpart?===
Well, you are not forced to but it is a _lot_ better. KPart allows powerful code reuse. Dcop allow scriptability and is very powerful. Given how simple it is to use these technology and how widely they are deployed, it is a shame not to use them if you can.

===How do I write a Makefile.am?===
The guide on how to write Makefile.ams is now a separate document, makefile_am_howto.

===How does the Makefile generation works?===
It uses autoconf and automake with another layer by the means of a program named am_edit. But don't try to understand how to use all that. It is quite complex and the strength of KDE is that you don't actually need to understand that stuff, a core-developer already did that for you.
Basically, automake transforms the Makefile.am into a Makefile.in, then am_edit runs and replaces in the Makefile.in all the KDE-specific tags with their real meaning, and configure will create a Makefile out of the Makefile.in

===Why does KDE produce .lo and .la files? Why are the files hidden in a .libs directory? Why is my executable a shellscript?===
Because KDE is using the GNU tool called "libtool". So the question forks into two: "Why use libtool?" and "Why does libtool create .lo and .la files, and shellscripts?".
KDE uses libtool for portability reasons. libtool takes care of the differences between the compilers and especially linkers on various platforms, so that we don't have to bother with that, even when writing shared libraries.
The .lo and .la files are used by libtool to add some information (read them, they are plain text), about object files and libraries. For instance, it remembers which libraries a given library depends upon. Without it, we'd still have to write link lines such as -lkparts -lkio -lkdeui -lkdecore -lqt -lXext -lX11 etc. etc. So you may find it a bit strange that things are "hidden" in .libs, but the gain is huge: complete portability, at no cost for the developers.

===What targets are available to make?===
*all: the default target (the one you get when typing "make").
*clean: removes all the generated files
*distclean: also removes the files generated by Makefile.cvs Not very useful within KDE (see dist for the "dist" concept and svn-clean for a better way to make really clean).
*dist: supposedly for making a tarball out of SVN sources, but not very well supported within KDE. Better use kdesdk/scripts/cvs2pack for that.
*force-reedit: re-run automake and am_edit on the Makefile.am
*install: well, install everything :)
*install-strip: install everything and strips binaries (removes debugging symbols).
*install-exec: only install the binaries and libraries
*install-data: only install the data files
*check: compiles the test programs (i.e. those defined with check_PROGRAMS). It is even possible to actually run some tests during "make check", see kdelibs/arts/tests/Makefile.am

===I have a checkout of SVN, there is no configure and no Makefile?===
Use make -f Makefile.cvs It will run all the Makefile generation steps

===How can I temporarily exclude certain directories from build?===
While hacking a program it might be useful to exclude certain directories from build that would otherwise be recompiled, but don't actually need to be.
Also, if you checked out source code that didn't compile and you don't have the time or knowledge to fix the error you might want to turn off compilation of the directory alltogether.
There are two cases. Toplevel directories, and subdirectories. For toplevel directories you can simply erase them (or not check them out).
If for some reason you don't want to do that, you can also set DO_NOT_COMPILE="someapp" before calling configure, this will make configure skip "someapp". To only compile very few toplevel dirs, instead of using DO_NOT_COMPILE to exclude most of them, you can list in a file named 'inst-apps', at the toplevel, the toplevel subdirs you want to compile.
To turn off compilation of any directory, including subdirectories, you have to modify the Makefile or Makefile.am files. Makefile.am is not recommended because that file is in KDE SVN and you could accidentally commit your changes. So we'll modify the Makefile instead here:
Open the Makefile in the directory immediately above the directory you want to exclude in a text editor and look for a variable SUBDIRS. It will often look somewhat like
SUBDIRS = share core ui . proxy taskmanager taskbar applets extensions data
Just remove the directory that you want to exclude and save your file. A new make will skip the directory you just removed.
Sometimes you'll have to look harder because the SUBDIRS variable consists of a number of other variables:
SUBDIRS = $(COMPILE_FIRST) $(TOPSUBDIRS) $(COMPILE_LAST)
Here you have to find the COMPILE_FIRST, TOPSUBDIRS and COMPILE_LAST variables. One of those contains the dir you want to exclude. Remove the directory where you find it and save the Makefile again.
To undo your changes you can either regenerate the Makefile from scratch or revert to an older backup (you did make one, did you? :-).
To regenerate a Makefile, just make force-reedit.
You can also copy the original line in the file when editing and make it a comment by prefixing a '#' in front of it. Then undoing the change is as easy as making the modified line a comment and removing the comment in the original line.

===What are the various compilation options?===
--enable-debug :
Add debug symbols, disable optimisations and turns logging of kdDebug() on.
--disable-debug:
The opposite of the previous one: enable optimisations and turns kdDebug() logging off.
--enable-final:
Concatenates all .cpp files into one big .all_cpp.cpp file, and compiles it in one go, instead of compiling each .cpp file on its own. This makes the whole compilation much faster, and often leads to better optimised code, but it also requires much more memory. And it often results in compilation errors when headers included by different source files clash one with the other, or when using c static functions with the same name in different source files.
This is a good thing to do at packaging time, but of course not for developers, since a change in one file means recompiling everything.
--disable-fast-perl
By default KDE uses perl instead of sh and sed to convert Makefile.in into Makefile. This is an addition to autoconf done by Michael Matz. You can use this option to disable this but it is a lot slower.

===Which compile option do you recommend?===
If you are a developer, you should definitely compile Qt and KDE with --enable-debug. You will then be able to debug your program even inside Qt and KDE function calls.
If you are just a user, you can still use --enable-debug. KDE will occupy more space on your hard disk but it won't slow down your desktop. The advantage is that you get stack trace when an application crash. If you can reproduce a crashing behaviour, go to bugs.kde.org, check that your bug doesn't exist yet and submit it. It will help us improve kde.
For Qt, the compilation options are explained in qt-copy/README.qt-copy.

===Tips to increase compilation speed?===
See --enable-final above :) . "make final" uses the all-in-one-file trick in the current directory even if --enable-final wasn't used, and "make no-final" does a normal compilation in the current directory even if --enable-final was used.
Include your moc files! Header files declaring a QObject descendant have to be run through moc to produce a .moc file. This .moc file has to be compiled, for which two possibilities exists: compile it separately, or #include it in the C++ file implementing that above mentioned class. The latter is more efficient in term of compilation speed. BTW, kdesdk/scripts/includemocs does this automatically.
Buy more ram, a faster machine and another processor. On a bi-PIII 866 MHz with 1GB of RAM, kde compiles at a decent speed :-)))

===There is a STRIP variable set in the Makefile but it doesn't seem to be used?===
The strip is done at install. To use it, use "make install-strip" instead of "make install".

===What indentation should I use?===
If you are working on an existing application, respect the author's indentation. Else, you can use whatever indentation you like.

===What is the difference between i18n and I18N_NOOP?===
If you do
QString translatedStuff = i18n("foobar");
translatedStuff will contain the translation of "foobar", while for
const char *markedStuff = I18N_NOOP("foobar");
markedStuff will still contain literal "foobar", but translators will know you want "foobar" translated so you can later on do QString translatedStuff = i18n(markedStuff); and get the translation of "foobar", which wouldn't work without that I18N_NOOP.
So, normally you want to just use i18n(), but in cases where you absolutely need to pass something untranslated, but still need to translate it later or in the case that you have something to be translated before the KInstance exists, use I18N_NOOP.

===What is this bug thing with QSpinNumber?===
There is a bug in QSpinNumber, that is not corrected yet. Use KSpinNumber instead, it has almost the same features.

===I get "virtual tables error"?===
This often comes from the moc files not being in sync with the sources, or not linked at all. Check that you are running the right moc. 'which moc' will tell it. Regenerate your moc files (make force-reedit; make clean; make).

===Trying to use dcop, I just added k_dcop to myClassHeader.h file but nothing specific seems to happen?===
Add myClassHeader.kidl to your Makefile.am and run make again.

===Some Makefile.am have a .stub file, what is it for?===
Stubs are not very documented. A stub allow you to view a dcop registered application as an object whose methods are its dcop slots. Usually, applications have an appnameIface.h file that contains all the dcop slots. Add a appnameIface.stub in your Makefile.am and use the object appnameIface. See for example kdebase/khelpcenter that uses a konqueror stub.

===I have added Q_OBJECT to myClassHeader.h but no moc files is generated?===
You need am_edit to reparse your Makefile.am to generate the correct Makefile. If it's the first Q_OBJECT you're using in this directory, you'll need to re-run Makefile.cvs or create_makefile from kdesdk/scripts. Otherwise, you can simply run "make force-reedit".

===To go quicker, I have coded my whole class in a cpp file, how do I get the moc and kidl files generated?===
Hmm, don't do that, if some of the classes use the Q_OBJECT macro. The KDE framework (am_edit) doesn't support this very well. Maybe METASOURCES=file.cpp might work for moc files though.

===I have developed a kpart (or a plugin). I don't want to install it yet because it is not finished but I need that KDE finds it when I request it using KTrader or KLibLoader. How do I do that?===
KDE searches its libraries in $KDEDIR/lib and in the lib directory of all the components of $KDEDIRS (note the additional 'S', this different from $KDEDIR). So, while you are still developing your library and don't want to install it, you can use this trick:
cd to your development directory, the one where your library is built.
Set up KDEDIRS so that it include your development directory: export KDEDIRS=`pwd`:$KDEDIR
Create a pseudo lib directory where KDE should find your component: ln -s .libs lib (all the objects and libraries are built in the .libs directory).
Run kbuildsycoca to inform KDE that it KDEDIRS has changed.
Now, KDE should find your library when using KTrader or KLibLoader.

===How can I install additional KDE stuff when I am not root?===
If want to install your application privately, configure it with another prefix: for $HOME/kdeprefix, use configure --prefix=$HOME/kdeprefix. Then let KDE know about this prefix: set KDEDIRS to $HOME/kdeprefix:$KDEDIR. To make KDE aware of new prefixes, one can also edit /etc/kderc and add
[Directories]
prefixes=/the/new/prefix

but this doesn't answer this specific question ;-)
Make sure to run "kbuildsycoca" after setting the new KDEDIRS.

===My kpart lib is not listed when I request it with KTrader===
The mimetype database must be rebuilt when you install new services (such as applications or parts). In theory this happens by itself (kded is watching those directories), but in doubt, run "kbuildsycoca".
The best way to debug trader-related problems is to use ktradertest: cd kdelibs/kio/tests; make ktradertest, then run ./ktradertest to see how to use it.

===I changed something in kdelibs, installed the new lib, but new KDE apps don't seem to use it?===
The solution is simple: start new apps from a command line, then they will use the new lib.
The reason is that applications started by other KDE applications (kicker, minicli, konqueror, etc.) are started via kdeinit, which loads the libs when KDE starts. So the "old" version of the libs keep being used. But if you want kdeinit to start using the new libs, simply restart it. This is done by typing kdeinit in a terminal.
This is necessary if you can't start things from the command line - e.g. for a kioslave. If you change something in kio, you need to restart kdeinit and kill the running kioslave, so that a new one is started.

===I'm developing both a KPart and a standalone application, how do I avoid duplicated code?===
Apps are often tempted to link to their part because they of course have much functionality in common. However this is wrong for the reasons below.
A lib is something you link to, a module is something you dlopen. You can't dlopen a lib ; you can't link to a module.
A lib has a version number and is installed in $libdir (e.g. $KDEDIR/lib) a module doesn't have a version number (in its name), it's more like a binary (we don't have konqueror-1.14.23 either :), and is installed into kde_moduledir (e.g. $KDEDIR/lib/kde3) (which means it's not in the search path for ld.so, so this breaks on systems without -rpath).
If you didn't understand the above, don't worry. The point is: you should NOT make your application link to your (or any other) KPart, nor any other kind of dlopened module.
The solutions
let the app dlopen the part. This is what KOffice does. However this limits the app to the very limited ReadOnlyPart/ReadWritePart API. Keep in mind that you can't call a non-virtual method whose implementation you don't link to. The solution is to define a ReadWritePart-derived class (like we have in koffice: KoDocument), with new virtual methods. Either this derived class has code (and you need a lib shared by the app and the part, see point 2 below), or an abstract interface (header file only) is enough. You can also use known interfaces to child objects of the part instead of changing the base class of the part itself - this is the solution used by e.g. KParts::BrowserExtension.
define a common library with the common classes and let both the part and the app use it. That library can be noinst_ or lib_, both work. In the first case the compiled object code is duplicated, in the second case a real versioned lib will be installed. The idea here is that the part itself is not available to the app, but instead the part is a very thin wrapper around the same classes as the app uses. Only KParts-specific stuff remains in the part.

===What is the best way to launch another app?===
There is a good answer in the kde2 porting instructions. Check kdelibs/KDE2PORTING.html, also there.

===How do I create and submit a patch to KDE?===
You have spotted a bug and you want to write the code to fix it. Or you want to code a specific feature. Sending a patch is very appreciated by developers. A tutorial is available but here is a description of how you should proceed:
Get the latest KDE using SVN to check that the code you want to write has not been added yet.
Check the bug database to see if your bug is not worked on.
Get in contact with the author. His/her name is in the about box or in the source header. If the project has a mailing-list, browse the archives to see if your bug/feature has not been the subject of any discussion. If you can't find any mailing lists or author, simply write to kde-devel.
Post a message explaining your intentions. It is important to inform the author(s) about what you are planning because somebody might already be working on your feature, or a better design could be proposed by the author, or he could give you some good advice.
Next step is to code your feature. It is usually a good idea to keep an original at hand and to work on a copy. This allow to check the behaviours of both versions of the code. Respect the author's indentation and naming scheme, code carefully, think about side-effects and test everything many times.
Using the latest KDE code, make a diff using either svn diff or a diff -uNp original-dir new-dir. Don't send reversed patch. The first argument of diff should be the old directory and the second the new directory.
Send a mail to the author/mailing-list with your patch as attachment (don't forget to attach it :-) ).
People usually have some remarks on your work and you must work further on your patch to improve it. It is common to see three or four submission before acceptation.
Ok, you have done it, your code has been included in KDE. You are now fully part of the KDE project. Thanx a lot.

===How do I make my application Xinerama and multi-head safe?===
Never make assumptions about the geometry of the "desktop" or the arrangement of the screens. Make use of the following functions from kglobalsettings.h:
static QRect KGlobalSettings::splashScreenDesktopGeometry();
static QRect KGlobalSettings::desktopGeometry(const QPoint& point);
static QRect KGlobalSettings::desktopGeometry(QWidget *w);
Use splashScreenDesktopGeometry() to determine the geometry of the desktop when you want to display an application splash screen. Use desktopGeometry() to determine the geometry of the desktop with respect to a given point on the desktop, or with respect to a given widget. Do not use the Qt class QDesktopWidget to determine these values yourself. The KDE functions take the user's settings into account, something the Qt functions cannot do.
It is ideal to try to avoid using the desktop geometry altogether. Your application will be much more standards compliant if you let the window manager place your windows for you. When this is not possible, you have the aforementioned functions available. Please beware that the geometry that is returned from these functions may not start at (0,0)! Do your math correctly!
One other caution: Both KWin and the NETWM specification have severe difficulties handling struts with Xinerama or "merged" displays. This can result in dead areas on the screen, for instance if kicker does not span a whole edge. There is not much that can be done about this, and you should try to avoid hacks to circumvent this at this time. We hope to find a proper solution for this soon.

===I get an error about KDE not finding UIC plugins, but I know they're installed. What's wrong?===
This is almost certainly an installation problem, not a KDE code problem. A number of problems can lead to this, but most likely you have more than one version of Qt laying around and the configure script is calling a different one than KDE is using.
Another thing that may help is to rebuild and reinstall your kdewidgets.so file, which is located in the kdelibs/kdewidgets directory. Note that if you *do* have multiple versions of Qt, this may compile against the wrong one.
This problem creeps up on various mailing lists occassionally, so looking at the archives on lists.kde.org may be helpful.

===I put some functions in anonymous namespace and someone reverted it and made those functions static, why?===
Symbols defined in a C++ anonymous namespace do NOT have internal linkage. Anonymous namespaces only give an unique name for that translation unit and that is it; they don't change the linkage of the symbol at all. Linkage isn't changed on those because the second phase of two-phase name lookup ignores functions with internal linkages. Also, entities with internal linkage cannot be used as template arguments.

===Can I delete a NULL pointer?===
Yes. Calling delete on a null pointer is a noop in C++. Having "if (ptr) delete ptr;" is redundant. Doing "ptr = 0;" after a delete is a good idea, especially if the delete can be called on it from a different code path.

==Debugging==
===How do I avoid Dr Konqi?===
You must set the environment variable KDE_DEBUG (to 1 or whatever you want in fact).

===What is a core file? How do I get a core file?===
A core file is an image of the memory when your application crashed. Using the core file, you can now which variables were set and where your application crashed.
Some distributions disable the generation of core files. To re-enable them, use "ulimit -c unlimited".
Once you have a core file for a crash, you can examine it with gdb appname core . This will open gdb on the core file for the given application. Once at the gdb prompt, the most useful command is "bt" which generates a backtrace of the crash.
For more information about how to use gdb, see this page.

===Is there a preferred way to print debug output on stderr?===
Yes, you must use kdDebug():

#include <kdebug.h>
kdDebug() << "KMyApp just started" << endl;
The syntax is much like cout, you can use many native types between the "<<". This will print out a debugging message, which will automatically be turned off at release time (by --disable-debug). In case you want the message to still be there during releases, because it's a warning or an error, use kdWarning() or kdError().
Components and libraries are advised to use a debug area number, as in kdDebug(1234). For this, the number must be registered in kdelibs/kdecore/kdebug.areas. Debug areas make it possible to turn off or on the debug output for specific area numbers, using the "kdebugdialog" program, which is part of kdebase. "kdebugdialog --fullmode" also permits to control where to log debug output. It is usually not necessary to register area numbers for standalone applications, unless it's so complex that you want to divide the output into several areas.
To make it clear: do NOT use qDebug(), this one doesn't get disabled at releases. Also avoid using assert() or kdFatal() which lead to a crash when something goes wrong, never nice for the user. Better detect the error, output a kdWarning or kdError, and recover if possible.

===What tools are available to debug my application?===
kdDebug() calls are a simple but efficient way to debug an application.
gdb, the GNU debugger, is the quickest way to execute step-by-step and investigate variables (prefer the 5.0 version, it is really better than the 4.1.x).
Valgrind
kdbg is a nice graphical frontend to gdb with a KDE GUI. It has support for many Qt types (including QString).
Memory leak tracer : See kdesdk/kmtrace. The README explains it all.
kdcop and dcop allow to browse the dcop interface and to easily make dcop calls.
Check this page and kdesdk, there are a bunch of useful scripts there.

===How do I print a QString in gdb?===
Check out kdesdk, and add this line to your ~/.gdbinit :
source /path/to/kde/sources/kdesdk/scripts/kde-devel-gdb
Then in gdb you can do printqstring myqstring to see its contents.
For instance, QString myqstring = QString::fromLatin1("contents"); can be examined using

(gdb) printqstring myqstring
$1 = "content"
See the kde-devel-gdb file for the other macros it defines.

===I have no symbol when I debug an app that uses kpart, what should I do?===
You must stop just after the main to load the debugging symbols of the shared library. After that, you can debug normally.
One can go as far as creating a gdb macro, to stop right after the part was loaded. For kword, by example, I use :
define startkword
break main
run
break 'KoDocument::KoDocument(int, QWidget *, char const *, QObject *, char const *, bool)' cont

===How do I debug an ioslave?===
See kdebase/kioslave/DEBUG.howto

Original question list by Philippe Fremy, answers by David Faure.
Contributions from: Marco Krohn, Malte Starostik, Andreas Pour, Waldo Bastian, Lars Knoll, Triskelios, Eric Sigra, Rolf Dubitzky, Martijn Klingens, Karl-Heinz Zimmer, George Staikos.
Please send additional questions, responses or comments to pfremy at kde dot org

Schedules/KOffice 1.5 Release Schedule

2006-12-23T13:24:17Z

Tbscope: Adding Koffice 1.5 release schedule, copied from developer.kde.org

All dates given here are subject to revision, but we will try our best to stick to them if possible. 
[mailto:boud@valdyas.org Boudewijn Rempt] is acting as release coordinator for the KOffice 1.5 release. 
KOffice 1.5 will be released independently from KDE.

==KOffice 1.5 Beta 1==
===January 15, 2006===
The HEAD branch of KOffice is frozen : no new features, bugfixes commits only, no commit that modifies an application's behaviour, and message freeze. This freeze will last till the release of KOffice 1.5! (Original date: Jan. 12, problems necessitated the slippage.)

===January 22, 2006===
KOffice is tagged KOFFICE_1_5_BETA1. Tarballs are made out of KOffice, for

==KOffice 1.5 Beta 1==
They are made public immediately, and given to packagers for creation of binary packages.
===January 31, 2006===
Announce KOffice 1.5 Beta 1.

===February 6, 2006===
Documentation is frozen. KPlato documentation will not be frozen before 13th February.

==KOffice 1.5 Beta 2==
===February 23, 2006===
Last day for translations.

===March 2, 2006===
Tag KOffice 1.5 Beta 2 (tags/koffice/1.5-beta2), create source packages.

===March 3, 2006===
Upload source packages to FTP server.

===March 7, 2006===
Announce KOffice 1.5 second beta

==KOffice 1.5 RC1==
===March 20 2006===
Tag KOffice 1.5 rc1 (tags/koffice/1.5-rc1). Test the tarballs. 
This week is for packagers to create binary packages.

===March 26, 2006===
Create changelogs, update the website

===March 27, 2006===
Announce KOffice 1.5 RC 1

==KOffice 1.5 Final==
===April 3 2006===
Tag KOffice 1.5 final version (tags/koffice/1.5.0). Test the tarballs. 
This week is for packagers to create binary packages.

===April 10, 2006===
The source and binary packages are uploaded to ftp.kde.org to give some time for the mirrors to get them.

===April 10, 2006===
Create changelogs, update the website

===April 11, 2006===
Announce KOffice 1.5

==Frequently Asked Questions==
;Which version of Qt is required?
Qt 3.3 or later, but not Qt 4.X
;Which version of kdelibs is required?
kdelibs 3.3 or later, but not kdelibs 4.X

Schedules/KOffice 1.6 Release Schedule

2006-12-23T13:16:31Z

Tbscope: Adding Koffice 1.6 release schedule, copied from developer.kde.org

All dates given here are subject to revision, but we will try our best to stick to them if possible. 
[mailto:cyb@lepi.org Cyrille Berger] is acting as release coordinator for the KOffice 1.6 release. 
KOffice 1.6 will be released independently from KDE. But new development will only happens for a few applications (mostly Krita, Kexi and KChart), other applications are developed for the version 2.0 of koffice.

==The genesis of the 1.6 version==
===Beginning of April, 2006===
The development for the 1.6 branch is started only for Krita, Kexi, KChart and KPlato, other parts of koffice are closed for now.

==KOffice 1.6 Alpha 1==
===July 10, 2006===
The 1.5 branch is officially close for bug fixes, except critical ones, all bug fixes must be applied to the 1.6 branch.

===August 1, 2006===
An alpha version of KOffice 1.6 is released.

==KOffice 1.6 Beta 1==
===August 15, 2006===
From that date, developers are asked to be carefull about the modification they make, no big changes, even if, adding small new features is still allowed. This is needed if we want to shorten the release cycle and still be sure to deliver a high quality new version.

===September 1, 2006===
The 1.6 branch of KOffice is frozen: no new features, bugfixes commits only, no commit that modifies an application's behaviour, and message freeze.

===September 1, 2006===
KOffice is tagged KOFFICE_1_6_BETA1. Tarballs are made out of KOffice, for

==KOffice 1.6 Beta 1==
They are made public immediately, and given to packagers for creation of binary packages.

===September 9, 2006===
Announce KOffice 1.6 Beta 1.
===September 13, 2006===
And documentation is frozen.

==KOffice 1.6 RC1==
===September 18, 2006===
Tag l10n for 1.6 rc1.

===September 19, 2006===
Tag KOffice 1.6 rc1 (tags/koffice/1.6-rc1). Test the tarballs. 
This week is for packagers to create binary packages.

===September 26, 2006===
Announce KOffice 1.6 RC 1

==KOffice 1.6 Final==
===October 6, 2006===
Tag KOffice 1.6 final version (tags/koffice/1.6.0). Test the tarballs. 
This week is for packagers to create binary packages.

===October 14, 2006===
The source and binary packages are uploaded to ftp.kde.org to give some time for the mirrors to get them.

===October 15, 2006===
Announce KOffice 1.6

==Koffice 1.6.1==
===From October 16, 2006 to October 22, 2006===
String freeze lift for kexi.

===November 6, 2006===
Tag 1.6.1 (tags/koffice/1.6.1).

===November 29, 2006===
Release 1.6.1.

==Koffice 1.6.2==
===From November 30, 2006 to December 7, 2006===
String freeze lift for kexi.

===January 15, 2007===
Tag 1.6.2 (tags/koffice/1.6.2).

===January 23, 2007===
Release 1.6.2.
 
{{box|Note|The release date of 1.6.1 and 1.6.2 are subject to change in the future, and are given only as indication. No 1.6.3 is planned for now, but if it's needed, either for translations or bug fixes, then one will be made.}}
 
==Frequently Asked Questions==
;Which version of Qt is required?
Qt 3.3 or later, but not Qt 4.X
;Which version of kdelibs is required?
kdelibs 3.3 or later, but not kdelibs 4.X

Schedules/KDE 3.0 Release Schedule

2006-12-23T13:03:12Z

Tbscope: Adding 3.0 schedule (copied from developer.kde.org)

The major change in KDE 3.0 will be the switch to Qt 3, as well as new features and bugfixes that involve bigger changes or require breaking binary compatibility. The plan is to make KDE ready for a long period of binary compatible releases.
The list of planned features can be found in a separate document.
All dates given here are subject to revision, but we will try our best to stick to them if possible.
 
[mailto:mueller@kde.org Dirk Mueller] is acting as release coordinator for the 3.0 releases.

==Monday September 24th, 2001: Preparing Alpha1==
The HEAD branch should be made ready to compile and work flawlessly with the current Qt 3.x beta / release version.

==Friday October 5th, 2001: Release Alpha1==
The HEAD branch is tagged as developer-release / alpha named KDE_2_9_RELEASE and tarballs are made.

==Friday November 2nd, 2001: Feature freeze==
The HEAD branch is frozen for feature commits that are not listed in the planned-feature document. Only bugfixes and the listed feature-commits are to be committed. Still, binary compatibility is not required, i18n string changes are allowed.

==Monday December 12th, 2001: Preparing Beta1==
KDE 3.0 Beta 1 is tagged and tarballs are made for testing. The HEAD branch is frozen except for urgent bug- and compile fixes.
The rest of the week is spent testing the tarballs, packaging and writing the announcement and changelog.

==Monday December 19th, 2001: Beta1 release==
Beta 1 is announced. The HEAD branch is frozen except for bugfixes and for the eventually outstanding feature commits listed in the planned-feature document. i18n string changes are to be kept at a minimum to allow translation teams that have to start from scratch to get a certain amount of work done.

==Monday January 28th, 2002: Preparing Beta2==
3.0 Beta 2 is tagged and tarballs are made for testing. The HEAD branch is frozen for release. i18n is completeley frozen for string changes by developers. Any nontrivial patches to CVS has to be approved by at least another developer. Announcement a week later.

==Wednesday February 13th, 2002: Announcement Beta2==
3.0 Beta2 is released to the public.

==Monday March 4th, 2002: Preparing RC 1==
3.0 RC1 tarballs are made and uploaded for testing.

==Friday March 8th, 2002: Preparing RC 2==
3.0 RC2 tarballs are made and uploaded for testing.

==Monday March 18th, 2002: Preparing RC 3==
3.0 RC3 tarballs are made and uploaded, which incorporate the CVS changes since RC2 tarballs. Remaining showstoppers are identified. The tarballs are made available to the packagers and put up on ftp. Binary packages will be publically announced together with the source tarballs as soon as they become available.

==Thursday March 21th, 2002: Decision about 3.0 final==
Manually selected changes since the RC3 tarballs are integrated into the proposed final tarballs, labeled RC4. A check of the showstopper list will decide if these tarballs are final. In this case, they're made available to the packagers and roughly a week later announced to the public. If not, the schedule is delayed by another week.

==Monday March 25th, 2002: tarballs made available to the packagers==
The final tarballs are made available to the packagers. The remaining week is used to prepare the changelog and the announcement.

==Wednesday April 3rd, 2002: KDE 3.0 announcement==
The final tarballs are made available on ftp.kde.org and the release is announced.

==Wednesday May 8th, 2002: 3.0.1 tarballs are made available to the packagers==
the KDE_3_0_BRANCH is tagged as KDE_3_0_1_RELEASE and tarballs are made for the packagers. Announcement roughly a week later.

==Wednesday May 22th, 2002: 3.0.1 is announced==
The tarballs and the binary packages are announced to the public after some delays.

==Monday June 24th, 2002: 3.0.2 tarballs are made available to the packagers==
the KDE_3_0_BRANCH is tagged as KDE_3_0_2_RELEASE and tarballs are made for the packagers. Announcement roughly a week later.

==Wed August 7th, 2002: 3.0.3 tarballs are made available to the packagers==
the KDE_3_0_BRANCH is tagged as KDE_3_0_3_RELEASE and tarballs are made for the packagers. Announcement roughly a week later.

==Wed September 25th, 2002: 3.0.4 tarballs are made available to the packagers==
the KDE_3_0_BRANCH is tagged as KDE_3_0_4_RELEASE and tarballs are made for the packagers. Announcement roughly a week later.

==Frequently Asked Questions==
;What's the deal with that feature-plan?:In the past, there were a lot of complaints about a rather long "freeze period", so this is an attempt to address this issue. Basically the idea is that you add an entry about what feature you want to finish in the 3.0 timeframe and mark it as done when you completed it. This helps me to get an overview about the outstanding changes and in return allows you to work on the missing parts even in the "freeze period". The feature-plan is open for commits till November, 2nd. ''Later additions'' require review first. I will try to respect outstanding entries in the release schedule. Please understand that although this gives you greater freedom over SVN, it also requires more discipline in making sure that your additions don't have unwanted side effects.

Schedules/KDE 3.1 Release Schedule

2006-12-23T12:57:42Z

Tbscope: Adding 3.1 schedule (copied from developer.kde.org but without the timetable)

KDE 3.1 is the first feature release in the KDE 3.x series.
The list of planned features can be found in a separate document.
All dates given here are subject to revision, but we will try our best to stick to them if possible. 
[mailto:mueller@kde.org Dirk Mueller] is acting as release coordinator for the 3.1 releases.

==Monday July 1, 2002: Preparing Alpha1 and feature plan freeze==
The HEAD branch is frozen for feature commits that are not listed in the planned-feature document. Only bugfixes and the listed feature-commits are to be committed. Still, binary compatibility is not required, i18n string changes are allowed. KDE 3.1 Alpha 1 is tagged and tarballs are made for testing.

==Monday July 8, 2002: Alpha1 release==
Alpha 1 is announced.

==Monday August 5, 2002: Preparing Beta1==
The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits. Tarballs are released to the packagers.

==Monday August 19, 2002: Announcement Beta1==
Beta 1 is announced.

==Monday September 16, 2002: Preparing Beta2==
3.1 Beta 2 is tagged and tarballs are made for testing. Announcement a week later.

==Monday September 23, 2002: Announcement Beta2==
3.1 Beta2 is released to the public.

==Monday September 30, 2002: i18n string freeze==
The i18n strings are frozen. The HEAD branch is frozen for release. Any non-trivial patches to CVS have to be approved by at least one other related developer.

==Monday October 28, 2002: Preparing RC 1==
3.1 RC1 tarballs are made and uploaded for testing.

==Monday November 4, 2002: Preparing RC 2==
3.1 RC2 tarballs are made and uploaded for testing.

==Monday November 11, 2002: Preparing RC 3==
3.1 RC3 tarballs are made and uploaded for testing.

==Sunday November 17th, 2002: Last day for i18n changes==
Last day for i18n commits which will go into 3.1 final.

==Monday November 18th, 2002: Preparing RC 4==
3.1 RC4 is tagged and being made available to the packagers.

==Friday December 6th, 2002: Preparing RC 5==
3.1 RC5 tarballs are generated and uploaded for testing.

==Friday January 3rd, 2003: Preparing RC 6==
3.1 RC6 tarballs are generated and uploaded for testing.

==Tuesday January 28th, 2003: KDE 3.1 Release==
KDE 3.1 was announced

==Friday March 7th, 2003: Preparing KDE 3.1.1==
KDE 3.1.1 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.

==Monday May 5th, 2003: Preparing KDE 3.1.2==
KDE 3.1.2 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.

==Monday July 14th, 2003: Preparing KDE 3.1.3==
KDE 3.1.3 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.

==Monday September 8th, 2003: Preparing KDE 3.1.4==
KDE 3.1.4 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.

==Frequently Asked Questions==
;What's the deal with that feature-plan?:In the past, there were a lot of complaints about a rather long "freeze period", so this is an attempt to address this issue. Basically the idea is that you add an entry about what feature you want to finish in the 3.1 timeframe and mark it as done when you completed it. This helps me to get an overview about the outstanding changes and in return allows you to work on the missing parts even in the "freeze period". The feature-plan is open for commits till July 1st. ''Later additions'' require review first. I will try to respect outstanding entries in the release schedule. Please understand that although this gives you greater freedom over SVN, it also requires more discipline in making sure that your additions don't have unwanted side effects.

Schedules/KDE 3.2 Release Schedule

2006-12-23T12:51:57Z

Tbscope: Adding 3.2 schedule (copied from developer.kde.org, but without the calender table)

KDE 3.2 is the second feature release in the KDE 3.x series.
The list of planned features can be found in a separate document.
All dates given here are subject to revision, but we will try our best to stick to them if possible.
[mailto:coolo@kde.org Stephan Kulow] is acting as release coordinator for the 3.2 releases.

==August 22nd - 31st, 2003: KDE conference==
Many KDE developers will meet in Nove Hrady, Czech Republic to discuss what final touches are missing for KDE 3.2 and update the feature plan.

==September 1st, 2003: Start of Release Cycle==
The HEAD branch is frozen for feature commits that are not listed in the planned-feature document. Only bugfixes and the listed feature-commits are to be committed. Still, binary compatibility is not required, i18n string changes are allowed. KDE 3.2 Alpha 1 is tagged and tarballs are made for testing.

==September 8th, 2003: Alpha1 release==
Alpha 1 ("Brokenboring") is announced. The incoming bugs will be reviewed for their severity.

==September 21st, 2003: Alpha2 prepared==
Alpha 2 is tagged and tarballs are made for testing.

==Sunday October 26th, 2003: Preparing Beta1==
The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits. Tarballs are released to the packagers.

==Wednesday November 26th, 2003: CVS is frozen for a moment==
The HEAD branch is only open for show stopper bug fixes and very secure changes.

==Sunday November 30th, 2003: Preparing Beta2==
The HEAD branch is tagged as Beta 2 and is released to the packagers. When the binaries are ready (to be expected 4th of December), the CVS opens again for the way it was after Beta1.
As most are to be expected to be on vacation towards the end of the year, commiters are asked to be very conservative with their changes and ask for second views on the lists.

==Sunday January 11th, 2004: CVS is frozen for release==
The HEAD branch is only open for show stopper bug fixes. A last time merge for the translations is done and as that has happened, the last remaining docs patches are put into CVS.

==Sunday January 18th, 2004: Release Candidate 1 is prepared==
Release Candidate 1 is prepared and tagged as KDE_3_2_0_RELEASE and a KDE_3_2_BRANCH is created. New Release Candidates will be released as show stopper bugs appear (and are fixed). If everything goes fine...

==Tuesday February 3rd, 2004: Release Party==
KDE 3.2 will be made available for download, PR materials will be uploaded to the website and an official announcement will follow.

==Sunday February 29th, 2004: Preparing KDE 3.2.1==
KDE 3.2.1 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.

==Sunday April 4th, 2004: Preparing KDE 3.2.2==
KDE 3.2.2 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.

==Sunday May 30th, 2004: Preparing KDE 3.2.3==
KDE 3.2.3 tarballs are generated and uploaded to the packagers. Announcement roughly a week later.

==Frequently Asked Questions==
;What's the deal with that feature-plan?:In the past, there were a lot of complaints about a rather long "freeze period", so this is an attempt to address this issue. Basically the idea is that you add an entry about what feature you want to finish in the 3.2 timeframe and mark it as done when you completed it. This helps me to get an overview about the outstanding changes and in return allows you to work on the missing parts even in the "freeze period". The feature-plan is open for commits till September 1st. ''Later additions'' require review first. I will try to respect outstanding entries in the release schedule. Please understand that although this gives you greater freedom over SVN, it also requires more discipline in making sure that your additions don't have unwanted side effects.

Schedules/KDE 3.3 Release Schedule

2006-12-23T12:42:31Z

Tbscope: Adding 3.3 schedule (copied from developer.kde.org)

KDE 3.3 is the third and quickest feature release in the KDE 3.x series.
The list of planned features can be found in a separate document.
All dates given here are subject to revision, but we will try our best to stick to them if possible.
[mailto:coolo@kde.org Stephan Kulow] is acting as release coordinator for the 3.3 releases.

==May 23rd, 2004: Alpha 1 prepared==
Alpha 1 will be source only, we do not want to take away packager resources from the KDE 3.2.3 happen around that date.

==June 1st, 2004: Start of Release==
The HEAD branch is frozen for feature commits that are not listed in the planned-feature document. Only bugfixes and the listed feature-commits are to be committed. Still, binary compatibility is not required, i18n string changes are allowed.

==June 22th, 2004: It's getting colder in CVS==
The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits till 27th. Features should mainly be done by now.

==June 26th, 2004: Beta1 prepared==
Beta 1 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.

==July 14th, 2004: Feature Freeze, Message Freeze==
After this date only bug fixes are allowed and the same message freeze applies as for released versions (i.e. only previously untranslated strings or clear errors in strings can be fixed - no new strings)
The HEAD branch is frozen for nonurgent commits till 18th.

==July 17th, 2004: Beta2 prepared==
Beta 2 is tagged and tarballs are made for testing. Tarballs are released to the packagers.

==August 4th, 2004: Total Freeze==
This is the very last for commiting anything that isn't reviewed on the development lists. If in doubt, ask the release coordinator.

==August 7st, 2004: RC1 prepared==
This release will happen very quickly, so the RC1 will already be labeled 3.3.0. So if there's nothing wrong with it, we will change the file names and are done (I can have dreams too, no?).
With this release a KDE_3_3_BRANCH is created and the final touches are applied in there.

==Wednesday August 18th, 2004: Targeted Release date==
August 21st starts the "aKademy" and I want to have this done before it, so there is little time left for the packagers and the PR team to get prepared for their trip to Ludwigsburg.

==Saturday October, 2nd, 2004: Tagging KDE_3_3_1_RELEASE==
The first translation and bug fix release: Will take its usual week of packaging

==Saturday November, 27th, 2004: Tagging KDE_3_3_2_RELEASE==
The second translation and bug fix release: Will take its usual week of packaging and testing

==Frequently Asked Questions==
;What's the deal with that feature-plan?:In the past, there were a lot of complaints about a rather long "freeze period", so this is an attempt to address this issue. Basically the idea is that you add an entry about what feature you want to finish in the 3.3 timeframe and mark it as done when you completed it. This helps me to get an overview about the outstanding changes and in return allows you to work on the missing parts even in the "freeze period". The feature-plan is open for commits till June 1st. ''Later additions'' require review first. I will try to respect outstanding entries in the release schedule. Please understand that although this gives you greater freedom over SVN, it also requires more discipline in making sure that your additions don't have unwanted side effects.

Schedules/KDE 3.4 Release Schedule

2006-12-23T12:36:13Z

Tbscope: Adding 3.4 schedule (copied from developer.kde.org)

KDE 3.4 is the fourth (and most likely last) feature release in the KDE 3.x series.
The list of planned features can be found in a separate document.
All dates given here are subject to revision, but we will try our best to stick to them if possible.
[mailto:coolo@kde.org Stephan Kulow] is acting as release coordinator for the 3.4 releases.

==December 6th, 2004: Alpha 1 prepared==
Alpha 1 will be source only - without translations.

==December 18th, 2004: HEAD is feature frozen==
The HEAD branch is frozen for feature commits that are not listed in the planned-feature document. Only bugfixes and the listed feature-commits are to be committed. Still, binary compatibility is not required, i18n string changes are allowed. The feature list closes for unreviewed changes that day.

==January 3rd, 2005: KDE_3_4_BETA1 tag==
The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits till 8th. Features should mainly be done by now.

==January 7th, 2005: Beta1 is prepared==
Beta 1 is prepared and released after some initial testing. The incoming bugs will be reviewed for their severity.

==February 2nd, 2005: Feature Freeze, Message Freeze==
After this date only bug fixes are allowed and the same message freeze applies as for released versions (i.e. only previously untranslated strings or clear errors in strings can be fixed - no new strings)
The HEAD branch is frozen for nonurgent commits till 6th
The only exception to the message freeze in the first week is the typo and style guide fixing of last minute feature commits.

==February 4th, 2005: KDE_3_4_BETA_2==
Beta 2 is tagged and tarballs are made for testing. Tarballs are released to the packagers.

==February 22nd, 2005: Total release freeze==
This is the very last for commiting anything that isn't reviewed on the development lists. If in doubt, ask the release coordinator.

==February 26th, 2005: Release Candidate 1==
This release will happen very quickly, so the RC1 will already be labeled 3.4.0. So if there's nothing wrong with it, we will change the file names and are done (I can have dreams too, no?).
With this release a KDE_3_4_BRANCH is created and the final touches are applied in there.

==Wednesday March 16th, 2005: Targeted Release date==

==Monday May 23rd, 2005: Creating tags/KDE/3.4.1/==
The first translation and bug fix release. Please add your changes to trunk/www/sites/www/announcements/changelogs/changelog3_4to3_4_1.php.

==Tuesday May 31st, 2005: Targeted 3.4.1 Release date==

==Wednesday July 20th, 2005: Creating tags/KDE/3.4.2/==
The second translation and bug fix release. Please add your changes to trunk/www/sites/www/announcements/changelogs/changelog3_4_1to3_4_2.php.

==Wednesday July 27th, 2005: Targeted 3.4.2 Release date==

==Wednesday October 5th, 2005: Creating tags/KDE/3.4.3/==
The third translation and bug fix release. Please add your changes to trunk/www/sites/www/announcements/changelogs/changelog3_4_2to3_4_3.php.

==Wednesday October 12th, 2005: Targeted 3.4.3 Release date==

==Frequently Asked Questions==
;What's the deal with that feature-plan?:In the past, there were a lot of complaints about a rather long "freeze period", so this is an attempt to address this issue. Basically the idea is that you add an entry about what feature you want to finish in the 3.4 timeframe and mark it as done when you completed it. This helps me to get an overview about the outstanding changes and in return allows you to work on the missing parts even in the "freeze period". The feature-plan is open for commits till December 18th 2004. ''Later additions'' require review first. I will try to respect outstanding entries in the release schedule. Please understand that although this gives you greater freedom over SVN, it also requires more discipline in making sure that your additions don't have unwanted side effects.