Frameworks/Policies

The strategy and policies for the KDE Frameworks effort is yet to be discussed and decided.

http://thread.gmane.org/gmane.comp.kde.devel.frameworks/37

This page is a starting point for further expansion.

Policies

Framework directory structure

All the frameworks will have the same directory structure which will follow some rules:

• The containing directory has the name of the technology (plasma, kio, itemmodels, etc.);
• At the top level we find the common files like README, TODO, MAINTAINER, etc.
• More comprehensive documentation go into a docs subdirectory
• The source code for the targets go into src subdirectory, if several payload are built (like a core lib and a gui layer on top) then src will contain one subdirectory per library: core, gui, widgets, etc.
• Code examples go into an examples subdirectory
• Automatic tests go into an autotests subdirectory
• Test applications go into a tests subdirectory

Frameworks have automatic unit tests

Enough said really... They must be unit tested with automatic unit tests.

Strive for Source Compatibility

Avoid removing API from the frameworks branch, even if it is replaced or deprecated. Prefer to implement the old API in terms of the new API.

In some cases this is very easy. For example, many APIs in KGlobal will be replaced as part of the frameworks effort.

• KGlobal::charsets() -> KCharsets::charsets()
• KGlobal::dirs() -> KStandardDirs::global() (or something?)
• KGlobal::ref() -> qApp->ref()
• KGlobal::deref() -> qApp->deref()

etc.

Removing this API from KGlobal is not necessary in most cases, and it introduces a porting burden which is best avoided.

There is unlikely to be a 1:1 mapping of old API to new API in every case, so how to implement the old API may not always be obvious. However, attempting to ensure that the older API remains useful should be at the front of our efforts and standards in the frameworks branch.