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

[Richard Dale]

Hi Luca

On Monday 06 June 2005 09:35, Luca Fascione wrote:
> Hello Richard,
> how are you?
I'm fine thanks. Did you make any progress with the tcl bindings? It seemed 
like the language was a bit too simple to work as well as ruby or perl.

> On a separate but related note,
> would think it would be possible to clean up smoke a bit, going to Qt4?
>
> I mean, there are a number of tiny things that could help developers a lot,
> like enforcing separate types for the indexes into the various arrays
> (so that the compiler will tell you if you're using an index coming from
> a class lookup to index into a type...),
> using hash tables instead of binary searches (say using STLport hashes)
> defining Smoke::t_ref as different from (Smoke::t_stack | Smoke::t_pointer)
I'm not all keen on using anything from the STL - the new QHash class would be 
better. I think you still need the same statically defined tables, as you've 
got to have something to load into the QHashes in the first place. It's just 
an optimization rather than a major change.

> And so on...
>
> If you guys are willing to do so, I could sit down and try to work this
> out...
>
> I would involve some degree of maintenance on all the code for the
> bindings, but I'm sure it would make for much clearer code both in Smoke
> and in the applications...
>
> I guess Ashley should be part of this discussion too, as well as the
> other binders...
I'll cc this to the kdebindings list - then we'll see perhaps..

> Let me know if this is of any interest
Yes, certainly I think that could be done. I have made some minor changes 
recently to improve introspection. The last four enum values are new in 
smoke.h 

    enum MethodFlags {
        mf_static = 0x01,
        mf_const = 0x02,
        mf_copyctor = 0x04,  // Copy constructor
        mf_internal = 0x08,   // For internal use only
        mf_enum = 0x10,   // An enum value
        mf_ctor = 0x20,
        mf_dtor = 0x40,
        mf_protected = 0x80
    };

They're not essential because you can always find out if something is a 
constructor by looking at the method name, but it's easier with a specific 
flag. So little tweaks like this and extra type safety are very useful, but 
the 'make Smoke more modular' is still the most important thing.

-- Richard

>
> 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 :(
> >
> >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
> >_______________________________________________
> >Kde-bindings mailing list
> >Kde-bindings at kde.org
> >https://mail.kde.org/mailman/listinfo/kde-bindings