[Kde-bindings] Re: Argument against the current direction of KDE bindings

[Richard Dale]

On Sunday 12 June 2005 04:14, Sebastian Sauer wrote:
> Hi dear readers,
>
> first sorry for my broken english. Would be much easier if we would talk
> c++ nativly :)
>
> > http://www.kdedevelopers.org/node/view/1150
>
> While this post looks for me like the try to get a talk about some ideas I
> may like to add an own idea/question/mark to a possible upcoming
> discussion. Please see it as a try to communicate with those devels that
> share my favor in scripting languages;
>
> I would like to have a common framework to embed bindings into C++/Qt/KDE
> applications. IMHO an application should be able to use transparently all
> support scripting languages without depending or knowing something about
> the language/interpreter itself. So, let's say e.g. the app uses Smoke as
> abstraction layer and just passes some scripting code to Smoke. Smoke
> itself then decides what scripting language is used, loads the matching
> interpreter and the scriptingcode got evaluated. This is somewhat similar
> to what the oo.org UNO API does. Please also see the following link to get
> a more detailed overview of this "wish".
I can't find your link. But Smoke is certainly designed to be language 
independent and could support more than one language at once.

> A while ago I seeked such a solution, but note very fast, that it isn't
> possible jet. Therefore I started my own implementation named Kross and
> used at Kexi right now ( see
> http://www.kexi-project.org/wiki/wikiview/index.php?Scripting ).
>
> Yes, I know that it's somewhat totaly different to what kdebindings likes
> to archive. But on the other hand, why? There is definitiv a needing for
> such a solution and IMHO Smoke is the try to have a common shared codebase.
> So, it looks for me, that Kross and Smoke try to archive similar tasks.
> Maybe some day it would be wise to try to have one solution for both tasks?
Yes, Kross sounds interesting. You are targetting scripting applications where 
it is sufficient to use slots/signals, but you don't need to override virtual 
methods and implement the complete api of kexi - just enough for scripting. 
Smoke/QtRuby/Korundum implement the complete Qt/KDE apis and so they are more 
aimed at RAD development than scripting. But it would be nice if Smoke could 
be more modular, and able to wrap plugin apis.

-- Richard