[Kde-bindings] Splitting up Qyoto und Kimono

Arno Rehn arno at arnorehn.de
Mon Dec 21 21:54:51 UTC 2009


On Saturday 19 December 2009 21:22:24 Richard Dale wrote:
> 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.
Ok. Manually sorting out the methods is quite painful, though.
I think we should either modify kalyptus to do the job (just for 4.4) or leave 
the current structure for 4.4 and modifiy it in 4.5. The new assembly 
generator which I'm currently working on should be ready until then and will 
do this quite nicely.

-- 
Arno Rehn
arno at arnorehn.de



More information about the Kde-bindings mailing list