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

Ian Monroe ian.monroe at gmail.com
Wed Oct 21 18:27:40 UTC 2009


On Wed, Oct 21, 2009 at 12:36 PM, 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 QtScript really the only thing that matters is startup time and
memory usage. The scripts for Amarok and other normal use-cases for
qtscript are going to be on the trivial side so runtime execution
speed really won't matter much. So slicing and dicing libsmokeqt is
something I'd be in full support of regardless of how things measure
out (unless it somehow increases start time). ;)

However I know we're not the only people using it....

> 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.

Of course QtScript doesn't. But yea split all this stuff up.

> Then the decision is whether it is a good idea to map one Qt module onto one
> Smoke library.
>
> 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



More information about the Kde-bindings mailing list