KDE 4 namespaces

Thiago Macieira thiago at kde.org
Mon May 9 00:57:53 BST 2005

Hello everyone,

with KDE 4 porting now imminent, I thought it was time to start the 
discussion on namespaces. If you've talked to me recently on the subject, 
you know I am pro-namespaces and would like to see everything deeply 

I know there are those who feel differently. Please voice your opinions.

One thing that should be done is a benchmarking of KDE 3 libraries with 
and without namespaces. If there is a great impact on the load time due 
to longer symbol names, this proposal should be scrapped.

Finally, do we have any platforms to support on which namespaces could 
cause problems?

Here follows my draft:
KDE 4 Namespace proposal

Many people are suggesting we start using namespaces in KDE 4. This
proposal outlines a few directive ideas about how to do that. As an
annex, it also proposes a new "home" for the current classes in KDE. It
is well known that many classes will change names, purpose, or may
disappear before KDE 4 is released. Hence, this list of classes is just
an overview of what KDE 4 would look like if it had today's classes.

The main drivers for using namespaces are:
- better organisation of our classes
- better mapping of classes to libraries
- benefitting from Qt4's split libraries (Core, Network, UI)
- less namespace pollution, leading to less chance of symbol duplication

The main drawbacks are:
- longer symbol names, leading to:
  - longer function prototypes
  - full name necessary for signals and slots
  - possible decrease in performance due to longer load times (longer
    strings to match)

This proposal does not deal with libraries or headers. If we decide to
use namespaces in KDE, we will have to discuss which library will have
which namespaces, and where our headers will be installed.

This proposal applies ONLY to the official KDE libraries in kdelibs.
This does not apply to program libraries, nor does it apply to the
programs themselves.

Libraries in playground/libs and kdereview/libs that wish to be moved on
to kdelibs will have to conform to the guidelines, if approved. However,
those libraries are not dealt with here.


These are the guidelines for namespaces in KDE 4 (proposal):

1) Strict namespace hierarchy
  That is, treat namespaces as if they were 1:1 mapped to libraries.
  This means  we shall have a "root" namespace, which shall be
  self-sufficient, except for  non-KDE symbols (i.e., Qt, STL, etc.).

  Other namespaces will be able to reference symbols from this "root"
  namespace, as well as other KDE namespaces, provided there is no
  closed circle on references.
  In other words, if namespace N1 is the root, namespace N2 will be able
  to use symbols from N1. Namespace N3 will be able to use symbols from
  N1 and N2; namespace N4 will be able to use symbols from N1, N2, N3,
  N4, and so on.

2) Two-level naming
  We should avoid creating namespaces inside namespaces, except for the
  top-level KDE namespace. Namespaces that group functions are
  acceptable, though (i.e., functions, members or not, should be at the
  fourth level).
  In other words, KDE::Core, KDE::UI, KDE::KIO are good names, but
  KDE::Core::Network isn't.
3) No K
  The KDE namespace provides sufficient distinction from non-KDE
  libraries.  We no longer have to name our classes starting with K.
4) Adherence to Qt4 libraries
  We should have at least one namespace making use of libQtCore only and
  one namespace using libQtCore and libQtNetwork. It would be
  desireable to have these namespaces mapped to their own libraries.
The namespaces

These are the proposed namespaces:

  KDE::Core   (the root namespace)
  KDE::IPC    (tentative naming)
Namespaces outside the "KDE libraries" (i.e., technologies of their own):
Not libraries:
  kimgio modules
  kded modules
Namespace KDE::Core
This namespace contains the core KDE classes, that make use of no
networking, no multimedia and no UI. This namespace is on a library of
its own, linked to libQtCore. It consists mostly of libkdecore classes,
and KCPUInfo from libkdefx. The UI, networking and audio classes should
be moved from this namespace.

Note KURL is not a networking class.

Namespace KDE::UnitTest
Uses: KDE::Core
Good question.

Namespace KDE::Network
Uses: KDE::Core
This namespace contains the KDE networking classes, and links to
libQtNetwork. It should contain the classes now found in
libkdecore/network, plus those of kssl and kdnssd that don't require
external libraries.

Namespace KDE::IPC
Uses: KDE::Core, KDE::Network
This namespace contains the Inter-Process Communication classes, or

- Will KDE::Core require this? If so, must be moved up, maybe to
  KDE::Core::IPC (violation of rule #2), or be left as a non-KDE
  namespace, like DCOP.

Namespace KDE::Multimedia
Uses: KDE::Core
This namespace is similar to KDE::Network, but unlike it there is no
libQtMultimedia to link against. This namespace is supposed to gather
all multimedia-related classes --- mainly the audio classes for our next
audio system backend.

- video-related classes, if any, won't depend on KDE::UI?
- should it link to libQtOpenGL?

Namespace KDE::UI
Uses: KDE::Core, KDE::Network, KDE::Multimedia
This namespace completes the Qt usage and links to libQtGui. It consists
mostly of libkdeui classes, plus the remaining kdefx functions and
classes, and those moved out of libkdecore (those related to
pixmaps/icons, accelerators, keys, shortcuts, clipboard, window manager,
themes, styles, effects and the NET classes).

- this is a good candidate for further breakup, even if not 1:1 mapped
  to a library. Maybe even in violation of rule #2 and use subdivisions
  (e.g., KDE::WM, KDE::UI::Styles, KDE::UI::Effects, etc.)
Namespace KDE::Wallet
Uses: KDE::Core, KDE::IPC
Contains the KWallet-related classes.

- subdivision on backend and client.

Namespace KDE::KIO
Uses: KDE::Core, KDE::Network, KDE::IPC, KDE::UI
Contains the KIO classes that are used in the applications (i.e., "KIO
masters"). This consists mostly of the non-ioslave-related classes found
in libkio.

- why not KDE::IO? Because "KIO" is the technology name.
- should the old libkfile classes be split off again? Maybe to KDE::Utils.

Namespace KDE::KIOSlave
Uses: KDE::Core, KDE::Network, KDE::IPC
Contains the KIO classes that are used in the ioslaves. It should not
link/use the UI-related namespaces, if possible.

Namespace KDE::KParts
Uses: KDE::UI
This contains the base classes for building KParts, mostly coming from

As an exception, the generic KParts interfaces should live in a
sub-namespace (KDE::KParts::Interfaces).

Namespace KDE::Utils
Uses: KDE::UI
This contains the libkutils classes, plus those miscellaneous classes
found in other libraries now homeless. In particular, I think the KFile*
classes should be moved here.

Namespace KDE::Print
Uses: KDE::UI, KDE::KParts
This namespace contains the printing-related classes and functions ---
that is, those found currently in libkdeprint.

- personally, I would prefer KDE::Utils::Print.

Namespace KDE::Spelling
Uses: KDE::KParts
This namespace contains the spell-checking-related functions and classes
that are currently found in kspell2.

- personally, I would prefer KDE::Utils::Spelling

Namespace KDE::AddressBook
Uses: KDE::UI
This namespace contains the addressbook-related classes, currently in
libkab and libkabc.

- why are there two libraries?
- personally, I would prefer KDE::Utils::AddressBook

Namespace KDE::NewStuff
Uses: KDE::KIO
Contains the GHNS-related classes, currently in libknewstuff.

- personally, I would prefer KDE::Utils::NewStuff

Namespace KDE::DNSSD
Uses: KDE::Core, KDE::Network
This namespace contains the DNS-SD functions and classes that require an
external library (libdnssd), currently found in libkdnssd.

- I wouldn't mind seeing this folded back into KDE::Network, but this
  would mean that almost every KDE application would load libdnssd. This
  is the only reason why I kept the separate namespace.
- if not, I would prefer KDE::Utils::DNSSD

Namespace KDE::SSL
Uses: KDE::KIO
This namespace contains the current KSSL* functions found in libkio.
This namespace is currently mis-named, since it should support
encryption techniques other than SSL.

- how much of this requires KIO classes? I think it should be split into
  non-UI classes (in KDE::Network, socket classes, maybe even the 
  certificate classes), UI classes (in KDE::UI,  like the certificate
  display  classes) and KIO classes.
- after the QCA integration, if we do it, reevaluate.

Namespace KDE::MDI
Uses: KDE::UI, KDE::KParts
This namespace contains the MDI-related classes, currently found in 

- does this really require KParts?
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

3. Ac seo woruld wearð geborod, swá se Scieppend cweað "Gewurde Unix" and 
wundor fremede and him "Unix" genemned, þæt is se rihtendgesamnung.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050508/0d52c18c/attachment.sig>

More information about the kde-core-devel mailing list