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
namespaced.
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.
Guidelines
----------
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::UnitTest
KDE::Network
KDE::IPC (tentative naming)
KDE::Multimedia
KDE::UI
KDE::Wallet
KDE::KIO
KDE::KIOSlave
KDE::Utils
KDE::KParts
KDE::Print
KDE::AddressBook
KDE::NewStuff
KDE::Spelling
KDE::DNSSD
KDE::SSL
KDE::MDI
Namespaces outside the "KDE libraries" (i.e., technologies of their own):
DCOP
KJS
khtml
Not libraries:
KatePart
khtmlpart
kcertpart
kdeinit
kioslaves
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
DCOP/DBUS/alike.
Questions:
- 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.
Questions:
- 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).
Questions:
- 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.
Questions:
- 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.
Questions
- 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
libkparts.
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.
Questions:
- 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.
Questions:
- 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.
Questions:
- 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.
Questions:
- 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.
Questions:
- 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.
Questions:
- 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
libkmdi.
Questions:
- 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