From kde-core-devel  Sat Aug 27 08:45:48 2005
From: Benjamin Meyer <ben () meyerhome ! net>
Date: Sat, 27 Aug 2005 08:45:48 +0000
To: kde-core-devel
Subject: Redefining kdelibs and kdebase
Message-Id: <5E4E8265-8651-4D08-A9F5-3C52129B6795 () meyerhome ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=112513238424281

Below is an idea that is not entirely my own (I am simply been the  
transcriber).  Around twenty or so people have looked at it and below  
is the current form after discussion.  In the main lab on the  
whiteboard it was drawn and talked about last night before closing  
and hopefully more talk will continue today/this week.

------------

-Biggest issue facing KDE is portability
o 3rd party developers that want to take advantage of what KDE has to  
offer
o KDE has no clear boundaries for libs and base making OS X and  
Window porting difficult.
o Not only to other OS's, but just using KDE applications in Xfce,  
Gnome, etc
With that in mind kdelibs and kdebase can be groups into the following

[KDE Workspace]  [KDE Base]
        \                           /
     [ KDE Frameworks ]
           |
     [ KDE Components ]
           |
        [ Qt  ]

Or a better image of it here:

http://www.icefox.net/gallery/pictures/2005/KDE/kde4.png

-----------

KDE Components
Consisting of portable, self contained classes that have unit tests.   
That classes should have as little dependancies upon other classes as  
possible.  Like Qt this should be divided up into core and ui  
libraries.  The maintainer should typically be the only commiters for  
each component.

Examples:
-KCmdLine
-KConfig
-KLED, KColorButton and other widgets
-A class to open a file, URL or a blank e-mail to someone
-A class to get paths such as temp, home, etc

KDE Frameworks
Consisting of portable interfaces and classes.  The frameworks are  
the infrastructure that is used to create applications.   It only has  
a dependancies to Desktop through C++ interfaces or dbus

Examples:
-Scripting language such as kjs or qsa
-XMLui
-KIO
-KHTML
-KPart
-Mainwindow
-Help system
-KConfigManager, ConfigCompiler
-Interfaces to common dialogs (file, print, etc)
-Address-book interface

KDE Workspace
Consisting of what is the desktop.  Libraries and applications don't  
need to be portable and probably will only work with X11.  On other  
desktops such as OS X, Windows and Gnome users wouldn't run  
applications that are included with this package.  Your average  
application shouldn't have dependancies to KDE desktop unless they  
are a component such as a screen-saver or panel applet.  Once  
libraries such as KIO are portable then they should be moved into  
frameworks.

Examples:
-KWin
-Plasma
-Screen-saver
-System Settings (KControl or whatever it will be)
-Session Management
-KDEPrint
-KFileDialog

KDE Base
Consisting of what runs on the desktop.  This packages is the basic  
set of applications beyond the desktop that KDE applications can  
assume are installed.  These applications should have no problem  
running on Windows, OS X or Gnome as stand alone applications is the  
user wanted them to be.  They would be useful applications in OS X  
etc.  This module might not contain everything that a user would  
expect a basic desktop to have (no calculator, spreadsheet etc) as  
those are in the rest of the modules (kdemultimedia, kdeutils etc)

Examples:
-File Manager
-Viewer
-Web Browser
-Help Center
-Konsole
-KWrite


How it would look in svn:
kdelibs/kde3support/
kdelibs/kdecomponents/
kdelibs/kdeframework/

kdeworkspace/

kdebase/

Even though componants, compat and framework are seperate packages  
they could be in kdelibs.  So end the end we would only be making one  
new module.