Redefining kdelibs and kdebase

[Nicolas Goutte]

On Saturday 27 August 2005 10:45, Benjamin Meyer wrote:
> 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

Does KIO also include the KIO slaves?

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

This would remove the "print to PDF" functionality for an KDE application 
running outside KDE.

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

You are talking about KWrite but not about Kate. Where do you plan to put 
Kate's library?

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

If there is an effort of making a split then please show it as separate 
modules too, otherwise it is nearly useless to make this discussion. (Also 
the kdelibs module is already big enough.)

Have a nice day!