[Kde-bindings] Splitting up the SMOKE library

[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:

+ qt_Smoke
+--+ qwt_Smoke
+--+ kde_Smoke
    +--+ whatever_in_kde_Smoke
+--+ qscintilla_Smoke 

I think this way would follow the design currently implemented in the 
bindings, but i would like to hear the opinion of Ashley though.

About the generation:
It should start generating and compiling qt_Smoke, and then the others in the 
order of the hierarchy. This way we could easily add more smokes later.

> -- Richard
>
>
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings



-- 
Thomas