Malaga Discussions II

[Sebastian Sauer]

Hi dear devels,

> Please note though that this whole discussion was just about scripting
> applicatins, neither about application development nor about heavy
> plugins. There is still something left to discuss, but we did a start.

http://lists.kde.org/?l=kde-bindings&m=111854258600143&w=2

So, we've at the moment a bunch of different solutions for the same problem; 
how to let Qt and other languages sleep together without paying alimony for 
ages.

> After the topic of IPC and a little break (with group photo), we had
> another discussion on the topic of scripting. We all agreed, that
> scripting will be a major component of KDE4 and that we need to make sure
> it's as good as possible.

Would it be possible to get some more informations what "as good as possible" 
means? I am specialy interessted in the way kdebindings likes to go in near 
future and if my KDE7-joke in the link above is going to be reality (so, 
rewrite kaliptus/smoke)?

> The discussion went a bit back and forth on the topics 'Do we support only
> one or several languages?' and 'If one, what language will that be?'. I
> was actually the strongest supporter of having a multi-language strategy,
> but in the end we left it to the developers there representing the actual
> kdebindings authors (Ian, Rich and Richard Dale) and they kind of agreed
> that one excellent binding is more than enough work. 

Will this be a hard limit or is the 'one excellent binding' more something 
like 'KDE official supports only kjs-scripting, but if you like to experiment 
we've some xyz bindings up too'?

While I agree that one excellent binding is better then 101 partly working 
solutions, I hope the provided solution still permits using of other 
(optional) bindings. So, design it as plugin-architektur with one official 
and fully supported plugin and leave that way the door open to the next 
scripting-hype.

I also would like to have, at least some day, some discussion how to merge 
kdebindings (wrote whole apps with scripting code) with some Kross-like 
(embed scripting into a native Qt/KDE app) solution.

> During the discussion 
> on the numbers of languages to support it was already obvious that the
> majority of developers wants kjs/qsa (which are said to differ only in
> details so far) to be _that_ language.

Quit funny cause the feedback I got last year from majority of users and 
developers is, that they would like to have python or <put your fav 
interpreter her> as preferred language instead of ecma like scripts.
Anyway, that's personal taste and shows one more time, that we maybe should 
provide at least an optional way to leave the decision up to the potential 
developer who decides that he likes to write some other binding and got 
frustrated by rewritting everything cause the existing scripting-solution is 
qsa/kjs only and couldn't be reused and, more worse, applications are bind to 
qsa/kjs only.
As already sayed above that doesn't mean to maintain a bunch of equivalent 
solutions for all existing interpreterlanguages like done today, rather then 
providing a plugin-framework where somebody is able to put his own 
scripting-binding in and use it as first class citizen even if not official 
supported by the KDE-project.

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder 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-core-devel/attachments/20050828/113d612b/attachment.sig>