Jump to content

KDE Core/Platform 11/PlatformVsFrameworks: Difference between revisions

From KDE Community Wiki
Sebas (talk | contribs)
more mores
Jlayt (talk | contribs)
No edit summary
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Definition of Frameworks and Platform =
{{warning|This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made.  Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.}}
 
= 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".


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 ==
The structure looks as follows:
* Useful as separate library
 
* platform independent
= 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.
 
Examples:
* Akonadi provides a complete solution for handling Email, Contacts, etc. Akonadi consists of all the needed components to accelerate your personal information management, boosting your business, making it easy to build god-like groupware clients.


== Platform ==


== Marketing Diagram ==
{|cellpadding="5" cellspacing="0" border="1"
|-
! colspan="3" | '''''KDE Frameworks'''''
| '''''KDE Look and Feel'''''
|-
|'''Solution'''
! colspan="2" |'''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''
|
|}


<hr>
<hr>
= What needs work here? =
= What needs work here? =
The following list gives an idea of some problems we see with splitting up our frameworks:
The following list gives an idea of some problems we see with splitting up our frameworks:
Line 21: Line 66:
* 8) duplicates functionality in Qt  
* 8) duplicates functionality in Qt  
* 9) should move into its own library
* 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 =
= Framework or Platform in kdelibs =
The list below indicates our _intended_ situation.
The list below indicates our _intended_ situation.


== Frameworks ==
== KDE Frameworks ==
=== Frameworks which need changes ===
 
* kdecore
=== Solutions ===
** auth 1)
* nepomuk
* kio 0)
* knewstuff 1) 2)
* kross 5) 2) 1)
* plasma
* The needed to locate components, apps and such (need a name?)
** services 8) (investigate with dfaure)
** ktrader 8) (investigate with dfaure)
** sycoca
* kdepimlibs
** akonadi 10)
 
=== Qt Addons / Functional ===
* kdecore
** compression 2)
** compression 2)
** kconfig 1), 8)
** date 3), 8)
** io 2), 5)
** io 2), 5)
** jobs 4)
** jobs 4)
** kernel - needs splitting up and further investigation
** klocale 8)
** kaboutdata 7)
** kaboutdata 7)
** sonnet 9)
** sonnet 9)
** kshareddatacache
* kjs
* kjsembed
* kparts 1) 2) 5)
* kdeui (most items are unclear, only listing clear ones here)
** itemviews
* kunitconversion 5)
* threadweaver
* kdepimlibs
** kblog
** kcalcore
** kholidays
** kimap
** kldap
** kmbox
** kmime
** kpimutils 11)
** ktnef
** kxmlrpcclient
** microblog 12)
** gpgme++/qgpgme
** syndication


=== Frameworks which look fine ===
=== Qt Addons / Integration ===
* kdecore
* kdecore
** kshareddatacache
** auth
** kconfig 1), 8)
** date 3), 8)
** kernel (except kaboutdata)
** ssl/ktcpsocket 8)
* kate
* kate
* dnssd
* dnssd
* kdeui (most items are unclear, only listing clear ones here)
** windowmanagement
* kpty
* kdesu (why public API?)
* solid
* kdepimlibs
** kontactinterface
** kpimidentities
** kpimtexteditor
** mailtransport
=== Look and Feel ===
* xmlgui's ui_standards.rc
* KStandardActions
* KStdGuiItem
* kglobal (?)
* kcomponentdata (?)
* kdewebkit (?)
* Probably more we missed at that level of details...


== Platform ==
== Platform ==
=== Platform bits with annotations ===
Platform is just a lousy name for our runtime components.
* 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 ==
== Trash ==
Line 68: Line 157:
* kdecore/util
* kdecore/util
* kfile
* kfile
* kdelibs/security
* kutils 1) 2) 5)

Latest revision as of 16:32, 6 June 2011

Warning

This page contains rough working notes from discussion sessions at Platform 11, the contents of which may not accurately reflect any decisions made. Please do not infer anything from these notes, official summaries of the conclusions reached will be made available for discussion as soon as possible.


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".

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 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.

Examples:

  • Akonadi provides a complete solution for handling Email, Contacts, etc. Akonadi consists of all the needed components to accelerate your personal information management, boosting your business, making it easy to build god-like groupware clients.


Marketing Diagram

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


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.

KDE Frameworks

Solutions

  • nepomuk
  • kio 0)
  • knewstuff 1) 2)
  • kross 5) 2) 1)
  • plasma
  • The needed to locate components, apps and such (need a name?)
    • services 8) (investigate with dfaure)
    • ktrader 8) (investigate with dfaure)
    • sycoca
  • kdepimlibs
    • akonadi 10)

Qt Addons / Functional

  • kdecore
    • compression 2)
    • io 2), 5)
    • jobs 4)
    • klocale 8)
    • kaboutdata 7)
    • sonnet 9)
    • kshareddatacache
  • kjs
  • kjsembed
  • kparts 1) 2) 5)
  • kdeui (most items are unclear, only listing clear ones here)
    • itemviews
  • kunitconversion 5)
  • threadweaver
  • kdepimlibs
    • kblog
    • kcalcore
    • kholidays
    • kimap
    • kldap
    • kmbox
    • kmime
    • kpimutils 11)
    • ktnef
    • kxmlrpcclient
    • microblog 12)
    • gpgme++/qgpgme
    • syndication

Qt Addons / Integration

  • kdecore
    • auth
    • kconfig 1), 8)
    • date 3), 8)
    • kernel (except kaboutdata)
    • ssl/ktcpsocket 8)
  • kate
  • dnssd
  • kdeui (most items are unclear, only listing clear ones here)
    • windowmanagement
  • kpty
  • kdesu (why public API?)
  • solid
  • kdepimlibs
    • kontactinterface
    • kpimidentities
    • kpimtexteditor
    • mailtransport

Look and Feel

  • xmlgui's ui_standards.rc
  • KStandardActions
  • KStdGuiItem
  • kglobal (?)
  • kcomponentdata (?)
  • kdewebkit (?)
  • Probably more we missed at that level of details...

Platform

Platform is just a lousy name for our runtime components.

Trash

  • kdecore/text

Don't know / undecided

  • kdecore/util
  • kfile
  • kdelibs/security
  • kutils 1) 2) 5)