[Kde-bindings] Re: Bounty Proposal: Improving KDE bindings

Peter Rockai (mornfall) me at mornfall.net
Tue Jun 7 15:00:22 UTC 2005

On Monday 06 June 2005 02:23, Richard Dale wrote:
> 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 :(
Sounds like a plan... Though i would allocate more bits to the module, since 
256 sounds like a limit some (crazy) app could even hit :).
> 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.
It'd be nice if you could put them up somewhere? I'm (obviously) in the 
"collecting data" stage, so any input welcome.
> 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.
The main problem seems to be that either the modules need static id's (ugly), 
or we need to resolve cross-module references dynamically. The actual index 
format is probably not that relevant. Anyhow, i was thinking about it in a 
tram today and what i got to: each module should index its dependencies 
[modules] (1-n) and use module-id << 20 | entity-id or something like this as 
an index (module 0 == self); it should also keep a smallish table of 
references to respective Smoke instances... the idea is to avoid writing over 
the static arrays so they can be kept shared by program instances (and disk 
image of the lib, too). The space overhead is in worst-case n^2, where n is 
number of modules, and time is a smallish constant (single indirection), so 
this could probably work reasonably well? We could also do this lazily, so 
unused references actually never get resolved? No idea if we save much 
(anything), since the initialisation time is still just n^2 and n is not 
going to be particularly huge either.

As for generation, doesn't change much, apart from we need the dependencies. I 
would probably gather that from .h files, as every .h processed can be 
recorded in a module description file and we can use #included .h files to 
track dependencies? Whatever, i'll look into this some more tonight :-). I 
also need to look better at moc4, but i suppose we still need a way to 
construct objects, even if qt can dispatch-by-name (and possibly args) for 
> > 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..

I just applied :-).

The Goal
  Provide bindings for KDE public APIs for the scripting language Ruby and 
make it easy for others to be added. The APIs should be generated 
automatically. KDE application plugin APIs should be covered.

  - reuse as much current (binding) code as possible
  - optionally rewrite kalyptus
  - either re-base the bindings around the Qt4 metaobject system or improve on 
smoke (modularise)


For the smoke vs moc4, Ashley seems to like moc4 for the purpose and i'm not 
un-keen about it either :). So i will probably look into this first, and if i 
need, either combine it with smoke or switch back to smoke for the effort.

I'm kind-of hoping to have the two of you (Ashley and Richard) as mentors, so 
i have someone to run to when i need :-).
> -- Richard


Peter Rockai | me()mornfall!net | prockai()redhat!com | +421907533216 
   http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation

More information about the Kde-bindings mailing list