KDE Core/Platform 11/PlatformVsFrameworks: Difference between revisions
< KDE Core | Platform 11
No edit summary |
No edit summary |
||
Line 3: | Line 3: | ||
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. | 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. | ||
== Framework == | {|cellpadding="5" cellspacing="0" border="1" | ||
|- | |||
|uses -> | |||
|'''Basics''' | |||
|'''Value Added''' | |||
|- | |||
|'''Functional''' | |||
|Used on some OS to plug a hole in them. Example: KDECore/Date+ktimezoned | |||
|No interaction | |||
|- | |||
|'''Integration''' | |||
|KDE Workspace specific. Example: Kephal+any module used | |||
|Desireable for the added value on any OS | |||
|} | |||
== Framework Definition == | |||
* Useful as separate library | * Useful as separate library | ||
* platform independent | * platform independent | ||
* Split in functional and integration | |||
===Functional frameworks=== | |||
===Integration frameworks=== | |||
== Platform == | == Platform Definition== | ||
* not necessarily portable | * not necessarily portable | ||
* ... | * ... |
Revision as of 16:31, 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.
uses -> | Basics | Value Added |
Functional | Used on some OS to plug a hole in them. Example: KDECore/Date+ktimezoned | No interaction |
Integration | KDE Workspace specific. Example: Kephal+any module used | Desireable for the added value on any OS |
Framework Definition
- 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