KDE 4 namespaces

[David Faure]

On Monday 09 May 2005 10:25, Stephan Kulow wrote:
> Am Montag 09 Mai 2005 02:42 schrieb Cornelius Schumacher:
> > I'm against changing our namespaces. 
> I'm with Cornelius here. Introducing namespaces to KDE seems to be
> more political correctness than technically feasible.
> 
> As beginner you would not just have to figure you want KConfig, no
> you would need to figure what name space is that in, what clashes
> a use "KDE::Core" introduces, what class names you will have to prefix
> to make it compile again, etc. etc. For little to no gain.

Yes. However we do use namespaces already, and in a very inconsistent way
(half of KIO is under the KIO namespace, the other half isn't). So although
I'm not necessarily in favour of Thiago's "namespaces everywhere",
I have a slight concern with the inconsistent use of namespaces in KIO.

How about a half-way solution?
* kdecore and kdeui are sort of extensions to Qt, they can very well follow
the same naming rules, i.e. keep the current KFoo and KBar there without namespaces.
(this basically removes Core, UI, Network and IPC from the initial proposal).

* but for libs "above" those (KIO, KParts, KABC, etc.), we would use namespaces.
We already mostly do, except for half of KIO.
On the other hand, a KIO-namespaced class can't move to kdecore later (like
KSycoca did), so we have to make sure to get it right from the start.
Let's see what this would look like:
KArchive -> KIO::Archive, KDirLister -> KIO::DirLister, KMimeType -> KIO::MimeType.
Why not? With typedefs to ease the porting, only signals/slots need to be fixed,
and I don't think anyone passes any of those in a signal :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).