KDE Application Developers' Checklist

Introduction

KDE developers, especially new ones, can easily overlook some tasks or features when developing applications or making changes to existing ones. KDE is a large system and, while much of the information exists somewhere, there is no one comprehensive set of development standards. This checklist attempts to summarize items to review before committing code to the KDE SVN to help prevent overlooking something. It is broken down into items for new applications, making changes to existing code, and general practices that apply to all KDE development.

New Applications

These items apply primarily when initially creating a new application.

put your code in the appropriate place in SVN (e.g. kdelibs, kdebase, kdeutils, kdenonbeta, etc.)
make sure you aren't unknowingly duplicating an existing application
provide a .desktop file
install MIME types, if applicable
provide application and toolbar icons
provide support for customizing toolbars and keybindings
implement Help/About box with authors and license information
write a manual
provide standard AUTHORS, ChangeLog, README, and TODO files
provide a .lsm (Linux Software Map) file
put licensing information at the top of each source file
provide .spec file for RPM packaging (or at least let packagers know about it)
provide debian directory and configuration files for Debian packaging (or at least let packagers know about it)
consider generating standalone source tar packages using svn2dist (found in kdesdk/scripts/svn2dist)
list generated files in .cvsignore files
register application at freshmeat.net and kde-apps.org
follow the standard KDE application/document/view design pattern
use the XML-based user interface framework
implement tooltips and What's This? help
announce on the kde-announce mailing list

Changes to Existing Applications

These items are applicable when making changes (enhancements or bug fixes) to existing code.

make sure you are working with the latest SVN source code
if you are not the maintainer, consider sending patches to the maintainer for review before being committed to SVN
if any files are changed or added, update packaging files in debian directory and RPM .spec file if required
make sure code compiles cleanly without errors or warnings
be aware of binary compatibility issues (applies to kdelibs)
close any relevant bugs in the KDE bug tracking system
increment application version string
update ChangeLog file
update the application's documentation
test your code before committing it
put meaningful text in the SVN commit message
document any significant changes in the change log announcement for the next KDE release

Best Practices

These are general items which apply to any coding done for KDE.

follow KDE user interface style guidelines
watch for portability issues (KDE runs on multiple platforms, not just Linux and x86)
check for components that your application depends on using tests in configure.in.in
put doxygen comments in source code
make sure all user visible text is localized
avoid duplicating facilities already in KDE or Qt libraries
support session management
implement features if applicable:
be aware of security issues due to sloppy coding. Be particularly careful with programs that run as root or setuid
consider using Qt designer for dialog layout
consider using kdevelop as an integrated development environment
provide keyboard accelerators for all functions for accessibility
use standard actions
use standard icons
keep aware of new KDE developments and release schedules by following the mailing lists, news sites, and the release schedule
follow the KDE development process rules during code freeze, message freeze, and hard freeze

References

Please send any additions, corrections, or comments to Jeff Tranter.