[Kde-bindings] Splitting up the SMOKE library

[Arno Rehn]

Am Sonntag, 15. Juli 2007 schrieb Thomas Moenicke:
> I think its actually a good idea. I already talked to Richard about
> improving the smoke API and it seems to be important not to break the
> current smoke-based bindings, so could you do it in a branch?
> Your idea allows us not only to split the smoke into its logical pieces,
> also it would be easier to add additional headers e.g. the ones of
> kdepim/akonadi. For doing it we need to resolve the dependencies of the
> class hierarchy in any way which could be done either with modifying the
> kalyptus generation script, but I would prefer a 'smoke browser' written in
> C++ that gives information about the installed classes and methods of an
> existing smoke and kalyptus could ask it when it generates e.g. smokeqwt.
> The benefit of such a thing would be the option of generating an API
> reference for documentation, asking for classes, methods and arguments in
> smoke and resolving
> dependencies.
I first thought about a text file generated by kalyptus that simply contains 
all the classes which are included in the corresponding Smoke lib. But such a 
SMOKE browser sounds a lot more interesting and flexible :)

> Basically having multiple smoke instances in one binding sounds feasible
> because its already prepared.
That's right, I always wondered why it's not yet done.

> On Sunday 15 July 2007 13:56:07 Arno Rehn wrote:
> > Hi,
> >
> > I just thought about splitting the SMOKE libraries, so that SmokeKDE
> > would only contain the KDE classes, SmokeQsci only QScintilla classes
> > etc., because at the moment it is rather ugly that we need to have all
> > the Qt classes again in SmokeKDE and can't split Qwt and QScintilla from
> > SmokeQt. In theory it is quite simple and I think I have something like a
> > concept. However it would require one or more changes in the API of
> > Smoke, so we also would have to update the sources of all the bindings
> > that depend on Smoke. The one change that will probably affect most parts
> > of the bindings is that I'd plan to make Smoke::Index a struct that looks
> > like
> >
> > struct Index {
> > 	short index;
> > 	Smoke *smoke;
> > };
>
> I dunno how it is in Qyoto, in QtRuby, PHP-Qt  and probably in PerlQt the
> pointer to the actually smoke is already in the struct smokeruby_object and
> could be set to the different smoke instances of smokekde, smokeqt,
> smokeqwt etc. It should automatically ask the parent smoke for classes and
> methods in case they cannot be found.
In Qyoto it's the same, we have a smokeqyoto_object. The main problem is the 
inheritance list of SMOKE. For example we have a KPushButton which inherits 
from QPushButton. So there has to be a class number for QPushButton in the 
inheritance list, but it hasn't been wrapped in the SmokeKDE lib. So we just 
use the class number of the SmokeQt lib. Of course SmokeKDE needs to know 
that this class is in another smoke lib, so we add a reference to that one. 
Now comes the real problem: If we need in our bindings language the parent 
class of KPushButton, we need to know the real index and the Smoke reference, 
else we can't find that class. That's the reason for the struct above.
A bit complicated to explain, but I hope I could make it understandable.

> > What do you think of splitting up Smoke? If you want to, I can give more
> > details on what I would do to split it up and make it work correctly.
>
> Please! :)
First I want to add an array of Smoke lib references, so we'd have something 
like this:

// don't have a reference at position 0
// because 0 is mostly used as a seperator in arrays
static Smoke* parents[] = { 0, kde_Smoke, qt_Smoke };
static short numParents = 2;

Then I'd modify the inheritanceList, like this:

// First number: index into parents[]
// numbers following until 0: index into the class list
static short qt_inheritanceList[] = {
	0,	// 0: (no super class)
	1, 123, 0,	// 1: KAction, in kde_Smoke
	2, 982, 0,	// 4: QWidget, in qt_Smoke
	// more list items...
};

Then also modify Smoke::Type to have another field for a reference to the 
Smoke lib.
The rest would need to be updated to go with the new types (e.g. 
qt_argumentList).
The functions in smoke.h would also need to automatically search in parent 
smoke libs for types and methods and return the appropiate Smoke::Index.

I'll first do some experiments locally and then check it into playground. It 
shouldn't be too hard. At least I hope so :)

-- 
Arno Rehn
arno at arnorehn.de