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

[Sebastian Sauer]

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

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?

Communication on this issue may something that isn't needed jet nor before 
KDE7 if we decide to rewrite whole KDE from scratch anyway (no, that's a 
joke :-) Anyway. If that happens nobody isn't able to hit me for not driving 
that issue/wish up earlier.

So, I am happy on any kind of note/feedback on this and wish everybody happy 
coding.

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder of/in http://www.koffice.org/kexi && http://www.kmldonkey.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20050612/c2a06a17/attachment.sig>