[Kde-bindings] Splitting up Qyoto und Kimono

[Arno Rehn]

Hi,

today I wanted to start on splitting up the Qyoto and Kimono bindings, but I 
encountered the following problem:
The class 'Qt' (in Qt.cs) contains several global methods from different Qt 
modules (like QDBusReplyFill()).
There are also a bunch of QDataStream's Read() and Write() methods (originally 
operator>> and operator<<), which actually belong to the QDataStream class.

The 'Qt' class is actually a mix of various C++ elements: First, it contains 
all functions and enums from the 'Qt' C++ namespace, which is ok.
But secondly it also contains all global functions from all the Qt modules, 
which is not the way it should work, I think.

I could imagine the following solutions:
1. Create special classes called 'QtCore', 'QtGui' etc. within the 'Qyoto' 
namespace and put the global functions there.
This would be out of line with the way it's done in other modules. There we 
have <Namespace>.Global for the global elements. This is not possible with a 
single 'Qyoto' namespace for all modules, though.

2. Get rid of the 'Qyoto' namespace and create seperate namespaces for QtCore, 
QtGui, KDECore, KDEUi etc. That's a bit more to type for the programmer, but 
it would make the bindings more clean, I think. We could also apply the 
'<Namespace>.Global' pattern here to create containers for the global 
functions.

Regardless of what we choose to do, splitting up the bindings will break 
existing applications. Is this a problem, given that the bindings belong to 
the 'public API' of KDE?

-- 
Arno Rehn
arno at arnorehn.de