[Kde-bindings] making smoke/korundum generate bindings for other things?

[Richard Dale]

On Saturday 25 June 2005 22:42, Gábor Lehel wrote:
> Could you give a quick overview of what writing marshallers consists
> of (eg, just a quick list, of what I have to add, and where)? I tried
> defining a valuelist macro for KCPathDataList in kdehandlers.cpp, as
> well as adjusting the KURL::List one to KCPathDataList after that, and
> whilst it compiled (not sure whether the former did), it doesn't work
> (returns a NULL pointer) -- this seems to be because smoke knows about
> KURL, but doesn't know about KCPathData (why? are structs (as opposed
> to classes) not processed?). 
Did you add an entry to the KDE_handlers array?

TypeHandler KDE_handlers[] = {
    ...
    { "KCPathDataList&", marshall_KCPathDataList },

But looking at the KCanvasPath.h header, it looks to me as though 
KCPathDataLists shouldn't be marshalled to ruby Arrays because it has methods 
like moveTo(), lineTo() and curveTo() which would be missing as an Array. So 
I think it should appear as a KDE::CPathDataList class in ruby. You may need 
to add some of the methods from QValueList so that you can insert and remove 
elements. One of the limitations of the current Smoke code generation is that 
it misses the methods from a template based superclass like 
'QValueList<KCPathData>'.

You will need to wrap the KCPathData struct seperately from Smoke as it 
doesn't have any accessor methods. See the code for wrapping the UDSAtom 
struct in Korundum.cpp - you need to add ruby accessor methods for each of 
the struct's fields.

> There is also stuff for KURL in 
> Korundum.cpp, but it seems for those I would have to define
> QDataStream << and >> operators for KCPathData, and I'd be getting in
> a bit over my head (I also looked at turning KCPathData into a ruby
> Struct, but didn't understand half the api docs, so the same applies)
> (and I'm hoping there's an easier way that's immediately visible to
> someone who actually knows how the whole thing works ;).
Yes, KCPathData will need to be either a normal ruby class or a ruby Struct, 
and that isn't automated at the moment. See my comment above about the 
UDSAtom code. I don't think you have to define an QDataStream operators for 
KCPathData, as there aren't any in the C++ api.

> I think I also managed to figure out what generate.pl doesn't like
> about KCanvasMatrix, KCanvasResource, and classes deriving from it:
> functions that return a reference. How do I deal with those? 
Can you send me your current list of headers in kde_header_list, and anything 
else I need to build the same code as you have? I can fix kalyptus code 
generation problems in the svn, as it won't affect any existing code 
generation for people who don't want to use KCanvas. It would be harder to do 
a version of Korundum.cpp and kdehandlers.cpp that could be built 
conditionally for KCanvas though. You would need some sort of 
'--enable-kcanvas=yes' configure flag, with suitable #ifdefs in the C++ code,  
and only link against libkdecore and libkcanvas if that was true.

> I tried 
> adding entries for the returned types to kalyptusDataDict.pm (as I
> remembered seeing 'type&' stuff in there), but it didn't make a
> difference (by the way, what purpose does it serve, as I remember you
> saying it's not necessary to add stuff to it?).
It's obsolete and should really be removed, I'm afraid the kalyptus code has 
got a bit old and crufty in parts and needs tidying up a bit.

-- Richard