[Kde-bindings] Re: Bounty Proposal: Improving KDE bindings
Richard Dale
Richard_Dale at tipitina.demon.co.uk
Mon Jun 6 06:23:16 UTC 2005
On Sunday 05 June 2005 20:48, KDE Bounties wrote:
> On Friday 03 June 2005 10:57, Peter Rockai (mornfall) wrote:
> > Synopsis
> > improve kde bindings in several areas (maintainability,
> > completeness, (speed?))
After porting to Qt 4, the most important priority is making the 'Smoke'
library more modular. At the moment all the Qt and KDE classes are in a
single large library. That works fine, but it isn't possible to support
optional plugin apis like kmail or kdevelop. In kdebindings/smoke/smoke.h a
Smoke::Index type is defined:
typedef short Index;
Instead of a short it needs to be an int, with the first 8 bits as a module id
followed by 24 bits as the index into the method or class table within that
module. So the problem is quite simple to specify, and it's also very clear
when you've finished because we'll suddenly be able to wrap every single
plugin api in KDE for ruby. And on the other hand, failure would mean it
won't work at all of course :(
Alex came up with the idea at aKademy, and after that I discussed it more with
Joseph Wenninger. We pretty got the runtime part sorted out, but the code
generation is the hard part. I've still got the mails with Joseph, so we will
have some sort of starting point.
Here is what is generated in kdebindings/smoke/kde/smokedata.cpp at the
moment:
Smoke* qt_Smoke = 0L;
// Create the Smoke instance encapsulating all the above.
void init_qt_Smoke() {
qt_Smoke = new Smoke(
qt_classes, 922,
qt_methods, 27770,
qt_methodMaps, 26307,
qt_methodNames, 20298,
qt_types, 2683,
qt_inheritanceList,
qt_argumentList,
qt_ambiguousMethodList,
qt_cast );
}
Those numbers are the ranges of the Smoke::Index described above. In the
future there needs to be one of these per module, and the lookup tables in
one module must be able refer to tables in other modules. The code that
generates Smoke is in kalyptus/kalyptus/kalyptusCxxToSmoke.pm.
> Sounds like an interesting project. A small tip is that before you send
> it off to Google try prepare one specific goal you'd like to address
> and have it as the project. Otherwise Google guys might not be too keen
> on accepting your project as it will be too vogue for them to judge the
> completeness of it when the due data hits.
> So I'd suggest that you talk to Richard and together try to figure out
> what you could do :)
I think delivering a bunch of working ruby plugin apis would be pretty
impressive and would be a big boost for ruby within KDE..
-- Richard
More information about the Kde-bindings
mailing list