Malaga Discussions II
mail at dipe.org
Sun Aug 28 21:29:43 BST 2005
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.
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
> 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,
> 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
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
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]
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel