[Kde-bindings] Splitting up the SMOKE library

[Thomas Moenicke]

On Monday 16 July 2007 16:33:52 Arno Rehn wrote:
> 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.

I just opened a branch in branches/work/kdebindings-smoke2/

-- 
Thomas