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

[Richard Dale]

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. 

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