[Kde-bindings] Creating Qyoto sources

[Richard Dale]

On Friday 19 January 2007 22:58, Arno Rehn wrote:
> Am Freitag, 19. Januar 2007 22:49 schrieb Richard Dale:
> > On Friday 19 January 2007 20:03, Arno Rehn wrote:
> > > Hi,
> > >
> > > I tried to let kalyptus create the Qyoto source, and it was somehow
> > > successfull, but if I compare the sizes of the resulting sources with
> > > the ones in SVN, I get different values. I used the headerlist
> > > provieded with qt4-qtruby, but there are some files missing, though
> > > they are in the headerlist.
> > >
> > > Do you use an other headerlist, Richard? Do you have a script for
> > > splitting the resulting files? I've written one by myself, but I get
> > > two Qt.cs files, one for QtGui and one for QtCore.
> > > Would be great if you could post them somewhere.
> >
> > I use the one in the kde svn trunk, KDE/kdebindings/smoke/qt/header_list.
> > I don't get two Qt.cs files though, everything should be combined into
> > one. To generate I just edit '-fsmoke' in smoke/qt/generate.pl and change
> > to '-fkimono'.
>
> I see, but you've splitted the sources into "gui", "core", "net" etc. in
> Qyoto svn, did you do that by hand? ;-)
Yes, just generate them in $kdebindings/smoke/qt, then use a little script
like:

cd trunk/playground/bindings/kimono
for DIR in core gui network opengl qdbus sql svg xml ; do
    cd $DIR
    for FILE in *.cs ; do
        cp $kdebindings/smoke/qt/$FILE .
    done
    cd ..
done

So it would be a good idea to add a script to qyoto to automate the code
generation some time.

> > I recently fixed a bug in parsing Q_PROPERTIES in kalyptus in the trunk,
> > which meant most of the methods in QToolBar.cs were being dropped. I
> > think Qt::ToolBarAreas still needs to be defined as an int as there
> > doesn't seem to be a definition of the enum values anywhere (or I haven't
> > found them at least).
>
> The definiton is in QtCore/qnamespace.h
> enum ToolBarArea {
>         LeftToolBarArea = 0x1,
>         RightToolBarArea = 0x2,
>         TopToolBarArea = 0x4,
>         BottomToolBarArea = 0x8,
>         ToolBarArea_Mask = 0xf,
>         AllToolBarAreas = ToolBarArea_Mask,
>         NoToolBarArea = 0
> }
>
> Then there is
> Q_DECLARE_FLAGS(ToolBarAreas, ToolBarArea)
> which seems to map ToolBarAreas to ToolBarArea. If we want a enum, the
> easiest way would be probably to make kalyptus look if there's a enum and
> if not, look for a Q_DECLARE_FLAGS.
So Qt::ToolBarArea is an enum and Qt::ToolBarAreas is a flag. Tthe definition
in kalyptusCxxToKimono.pm is actually correct and Qt::ToolBarAreas should map
onto an int in C#.

> > One thing I was thinking of doing was to use partial classes, and rather
> > have boiler plate code inside kalyptus, have it in the qyoto project as
> > partial classes. For instance, split QApplication.cs and have
> > QApplicationExtras.cs too, where extras would have the custom versions of
> > the QApplication constructors. I'm not sure about the name:
> > QApplicationExtras.cs,
> > QApplicationPartial.cs, QApplicationCustom.cs or other?
>
> I'd use QApplicationExtras.cs, would be easiest to understand, in my
> opinion.
Yes, ok we should split out the C# code from kalyptusCxxToKimono.pm into
partial classes called *Extras.cs.

-- Richard