KDE Core/Platform 11/PlatformVsFrameworks

Executive Summary

The following is how we talk about what we previously referred to as "the KDE Platform". The KDE Platform is now called the "KDE Frameworks", consisting of "Qt Addons" (functional and integration addons) and complete "KDE Solutions".

The structure looks as follows:

KDE Frameworks

The KDE Frameworks provide high-level components to build applications on.

Qt Addons

KDE's Qt Addons provide functionality on top of Qt. These addons are easy to use in your application. KDE's Qt Addons provide complex functionality through an convenient, Qt-style API.

KDE's Qt Addons are liberally licensed under the LGPL.

Examples: - The "Date & Time" Addons provide a complete and intuitive high-level API for dealing with time and all of its complexity, including timezones, holidays, different calendaring systems and more.

KDE Solutions

KDE's Solutions provide ready-made components you can use on a conceptionally high level.

Definition of Frameworks and Platform

In our communication we want to use Frameworks, since this communicates the modularity of our libraries better than the term "platform", which gives a more monolithic, either-or impression.

The KDE Frameworks

KDE Frameworks			KDE Look and Feel
Solution	Qt Addons
	Integration	Functional
Library with a hard dependency on a KDE Runtime component, and the KDE Runtime component itself. Examples: Akonadi, KIO	Library with optional dependency on a KDE Runtime component used only to workaround OS missing features (implementation detail). Examples: Date, Solid	Self-contained library, not using any KDE Runtime component. Example: KImap	Examples: KStandardActions, XML GUI, UI Standards
	Marketing side: actually indicate how difficult it is to deploy because of runtime dependencies	Anything belonging to Functional cannot use anything coming from Integration

• Useful as separate library
• platform independent
• Split in functional and integration

Platform Definition

• not necessarily portable
• ...

What needs work here?

The following list gives an idea of some problems we see with splitting up our frameworks:

• 1) needs sycoca
• 2) uses mimetype/xdg
• 3) uses kded
• 4) kglobal used, but only for ref/deref (which can maybe move into Qt)
• 5) uses kglobal (in a non-trivial way)
• 6) uses kaboutdata
• 7) should be optional
• 8) duplicates functionality in Qt
• 9) should move into its own library
• 10) Make Qt only/split out KDE-specific parts
• 11) No clear picture
• 12) Should not be made public

Framework or Platform in kdelibs

The list below indicates our _intended_ situation.

Frameworks

Functional

• kdecore
  • compression 2)
  • date 3), 8)
  • io 2), 5)
  • jobs 4)
  • kaboutdata 7)
  • sonnet 9)
  • kshareddatacache
• dnssd
• kdeui (most items are unclear, only listing clear ones here)
  • itemviews
• kdepimlibs
  • akonadi 10)
  • kblog
  • kcalcore
  • kholidays
  • kimap
  • kldap
  • kmbox
  • kmime
  • kpimutils 11)
  • ktnef
  • kxmlrpcclient
  • microblog 12)
  • gpgme++/qgpgme
  • syndacation

Integration

• kdecore
  • auth
  • kconfig 1), 8)
  • kernel (except kaboutdata)
• kate
• kdeui (most items are unclear, only listing clear ones here)
  • windowmanagement
• kdepimlibs
  • kontactinterface
  • kpimidentities
  • kpimtexteditor
  • mailtransport

Platform

Platform bits with annotations

• klocale 8)
• ssl/ktcpsocket 8)
• services 8) (investigate with dfaure)
• ktrader 8) (investigate with dfaure)

Platform bits without

• kded
• kglobal
• kcomponentdata
• sycoca
• kdesu
• kwebkit

Trash

• kdecore/text

Don't know / undecided

• kdecore/util
• kfile