Revision as of 18:25, 3 June 2011

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

Solution	Qt Addons	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

Useful as separate library
platform independent
Split in functional and integration

Functional frameworks

Integration frameworks

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

@@ Line 2: / Line 2: @@
 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 ==
 {|cellpadding="5" cellspacing="0" border="1"
 |-
-|uses ->
+|'''Solution'''
-|'''Basics'''
+|'''Qt Addons'''
-|'''Value Added'''
+|'''Qt Addons'''
 |-
-|'''Functional'''
+|
-|Used on some OS to plug a hole in them. Example: KDECore/Date+ktimezoned
+|''Integration''
-|No interaction
+|''Functional''
 |-
-|'''Integration'''
+|Library with a hard dependency on a KDE Runtime component, and the KDE Runtime component itself. Examples: Akonadi, KIO
-|KDE Workspace specific. Example: Kephal+any module used
+|Library with optional dependency on a KDE Runtime component used only to workaround OS missing features (implementation detail). Examples: Date, Solid
-|Desireable for the added value on any OS
+|Self-contained library, not using any KDE Runtime component. Example: KImap
 |}
-== Framework Definition ==
 * Useful as separate library
 * platform independent