[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] Splitting up the SMOKE library
From:       Thomas Moenicke <tm () php-qt ! org>
Date:       2007-07-15 13:08:07
Message-ID: 200707151508.07753.tm () php-qt ! org
[Download RAW message or body]

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.
Basically having multiple smoke instances in one binding sounds feasible 
because its already prepared.

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.

> 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! :)

-- 
Thomas
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]