KDE Application Developer's 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 CVS 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.
- make sure you aren't 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 .lsm (Linux Software Map) file
- put licensing information at the top of each source file
- provide .spec file for RPM packaging
- provide debian directory and configuration files for Debian packaging
- list generated files in .cvsignore files
- register application at freshmeat.net
- 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 CVS source code
- if you are not the maintainer, consider sending patches to
the maintainer for review before being committed to CVS
- 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
- close any relevant bugs in the KDE bug tracking system
- increment application version string
- update ChangeLog file
- test your code before committing it
- put meaningful text in the CVS commit message
Best Practices
These are general items which apply to any coding done for KDE.
- follow KDE coding guidelines
- follow KDE user interface style guide
- watch for portability issues (KDE runs on multiple platforms, not
just Linux and x86)
- put kdoc 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:
- panel system tray
- drag & drop
- printing
- kparts componentization
- dcop
- sound
- 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 mailing lists and news sites
References
- KDE Developer's web site
-
KDE 2.0 Development book at Andamoooka
-
KDE Developer's HOWTO