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

[Richard Dale]

On Tuesday 07 June 2005 17:00, Peter Rockai \(mornfall\) wrote:
> 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.
Yes ok, I'll forward them to you.

> > 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. 
Yes, it would be more flexible if they could be fixed up 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?
Yes, you could dynamically the underlying libs on demand.

>  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 us...
Yes, you need to know which classes are in which libraries to have a one to 
one mapping between the Smoke library and the underlying lib.

> > > 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 :-).
OK, good luck!  W'e'll see what happens then.

> 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.
>
> Subgoals
>   - 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)
Well, I'm not sure we need to rewrite kalyptus - it's perfectly good at 
parsing the headers. Ashley had an idea to use a translation unit dump to 
generate the code instead. On the other hand you need to get stuff from 
comments in the headers like '@deprected' and so.

> ----
>
> 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 :-).
Well, since I posted the original Ashley has started to discuss an improved 
Smoke - which obviously changes the plan..  So best to see what he comes up 
with, and whether he would be a mentor.

-- Richard