KDE Core/Platform 11/PlatformVsFrameworks

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.

Framework

• Useful as separate library
• platform independent

Platform

• 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

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