[Kde-bindings] Splitting up the SMOKE library

[Arno Rehn]

Am Montag, 16. Juli 2007 schrieb Thomas Moenicke:
> On Monday 16 July 2007 11:31:12 Richard Dale wrote:
> > On Sunday 15 July 2007, 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;
> > > };
> > >
> > > 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.
> >
> > That's exactly what the existing design does, but it has a subclass of
> > Smoke (from smoke.h), for every module. Instead of having just a global
> > qt_Smoke handle, we have one for each module. There are quite a few
> > places where the global 'qt_Smoke' handle is used, and we would need to
> > think through how to change them to use a module-specific handle instead.
> > Or find a way of getting from qt_Smoke to the other modules in the
> > runtime?
>
> The kalyptus generator should generate the qt_Smoke instance in
> smokedata.cpp only for the Qt smoke, for KDE smoke it should have a
> kde_Smoke instance which has a pointer to qt_Smoke. In case the inline
> methods of kde_Smoke don't find the index they can ask the qt_Smoke before
> it returns 0. Thus we can create a hierarchy of dependencies and don't need
> to touch too much in the implementations:
That's exactly what I've done this night. I added an Smoke* array to smoke.h 
called parentModules which contains pointers to the parent modules.
findMethod() first looks up the class (possibly in one of the parent modules) 
and returns the index and a pointer to the smoke module in which the class 
was found. To get the index of the munged method name, we start searching 
from the module in which the class was found up the hierachy, to be sure the 
right munged method name is found (maybe in some lower level module exists 
the same munged name again). In that module we finally look for the real 
methodMap we want to have.

-- 
Arno Rehn
arno at arnorehn.de