[Kde-bindings] Splitting up Qyoto und Kimono

[Richard Dale]

On Saturday 19 December 2009 06:31:38 pm Arno Rehn wrote:
> 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.
That sounds best out of the two solutions to me. But leave the one in QtCore 
as Qt.cs though and assume that nearly all the important stuff will still be in 
the same class as before. I don't think people will be using QDataStreams that 
much, and the QDBus method would certainly be better in the QtDBus module.

> 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.
Getting rid of the Qyoto namespace seems like overkill to me.

> 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?
 I don't think it is too big a change if we keep the Qt.cs class with a few 
things removed, and keep the Qyoto namespace. They gain the flexibiltiy of only 
loading the parts of Qt they actually need, which i think is a good trade off.

-- Richard