[Kde-bindings] Splitting up the Smoke qt library into modules

[Ian Monroe]

On 10/21/09, Richard Dale <rdale at foton.es> wrote:
> While we're discussing BIC changes to the smoke libs, I wonder if it would
> be
> a good idea to split up the libsmokeqt library into small libs. The small
> size
> of the Smoke libs is becoming a big advantage relative to other bindings
> libraries, and it we split them up a bit maybe the advantage would  be
> larger
> still. Or is the a performance tradeoff in that searches for a class or
> method
> would have to cross Smoke module boundaries more often and that would slow
> things down? It is worth measuring somehow?
>
> For a start I really thing we should remove QtXml and QtSql from the base
> Smoke library as nearly all dynamic languages have their own versions of
> there
> which are quite likely to be better than a wrapped C++ version. For example,
> there in no point in using the QtSql classes in Ruby because Rails
> ActiveRecord is so much better.
>
> Then the decision is whether it is a good idea to map one Qt module onto one
> Smoke library.

Would it make sense to split up qtgui? a basic module, a qgv module
and the rest for instance. QtGui is just sooo much bigger then any
other module, but like I'm guessing most amarok scripts use a fairly
limited subset (and other users of smoke are probably in the same
boat.)

Would want to proceed with some real data to decide what is basic,
maybe write some scripts to count class usage in various users of
smoke.

We should perhaps delay this decision until we know what the cost of
splitting is. Just putting the idea out there.

 >
> One example for me, is that I think a separate QtCore smoke library would be
> useful for Semantic web applications, as I could use the Ruby bindings for
> QtCore, Soprano with the ActiveRDF Virtuoso adaptor with Wt::Ruby for the
> web
> app without the overhead of the QtGui library.
>
> -- Richard
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>