[Kde-bindings] Smoke Help

[Arno Rehn]

On Monday 29 March 2010 17:55:18 Zeke Connor wrote:
> Hello,
> 
> I'm wanting to make use of Smoke to make my current library accessible from
> Python, Ruby, Javascript, QtScript so that I can allow users to use it in
> Kross or even in the language itself for non-purpose of my main
> application. But I cannot seem to really find a guide on using Smoke. What
> be the easily way of doing this?
Just to clarify things a bit: Kross and Smoke don't have any relationship, 
i.e. you don't need a Smoke lib to implement Kross in your application. From 
what I know (no guarantee that the following is correct):

Kross will let you expose a subset of the API to a variety of script-plugins. 
Your app doesn't have to know anything about the specific language, it's all 
managed by Kross.
The good thing here is that it seems to be fairly easy to expose your API to 
the scripting languages, but then again it's only a subset of the available 
API (as I understand it).

Smoke on the other hand will create a complete lib that let's people call 
every possible method of your API, making nearly 100% of it available to other 
languages.
The good thing with smoke-based bindings is that they're completely 
transparent to apps. Plugins written in a language with smoke-based bindings 
make use of rubypluginfactory and kimonopluginfactory, respectively, which 
then look like any other C++ plugin to your app. So you can easily create 
KParts or KIO slaves with Smoke-based bindings and the apps won't even notice 
the difference.
The downside here is that creating smoke libs is slightly more work than 
exposing API with Kross. It has been simplified very much with our new 
'smokegen' sources generator, though.

I've just finished writing a tutorial for generating smoke libs, see here:
http://techbase.kde.org/Development/Languages/Smoke

Now we only need more tutorials on how to create QtRuby and Qyoto extensions 
from this Smoke lib.

-- 
Arno Rehn
arno at arnorehn.de