[Kde-bindings] KjsEmbed - what is now and what will be?

[Ian Monroe]

On Sat, Feb 27, 2010 at 7:19 PM, Andreas Marschke
<xxtjaxx at googlemail.com> wrote:
>> But users have to figure out dependencies for scripts. Professionals
>> handle the dependencies for Amarok.
> Thats quite right, but in case of Linux Distributions the Packagers who are
> packeging amarok (who are packagers aswell) seperate this for the user.
> Windows ports of Amarok can include these (possibly free as in freedom) pieces
> of libraries that one might need. And in case one can also see on the wiki
> what is additionally downloadable and usable for plugins in Amarok for an
> example. Recently, I had been involved in showing a friend how Amarok and
> QtScripting is and so he can try it out on  his windows-machine we went for
> the Amarok Download site and lo and behold you had a little information to
> download KDE for win before downloading and installing Amarok. So why not say
> there aswell : "If you want to have scripting for language foo or bar go ahead
> and download this file"?

You really think the Amarok for Windows install experience is a good
role model? I don't think its great, we have a goal to simplify it
into a single .exe that does everything with no options.

anyways you missed my original point. There are *tons* of python and
ruby libraries out there. It's part of their power. It probably
would've been OK to have "Ruby + Korundum" and to enforce no external
dependencies via social means. But we opted to go with "QtScript +
qscriptgenerator". What was never an option was
Ruby/QtScript/Python/anything else Kross thought up in the future, due
to our experience from Amarok 1.4.

>
>> No, its a smoke binding for QtScript. The Smoke library is how we
>> reveal KDE and Qt APIs to Ruby and C# etc and now JavaScript.
>> KJS predates QtScript so it wasn't a duplicated effort at the time.
> As far as I understood it from a friends explanation Smoke would be for real
> plugins, Kross is for Scripting. But I myself mad a small plugin
> infrastructure implemented in the application. The only thing it will need
> right now are finishing touches such as a UI the background IO work was fine
> and worked.
> No Smoke, only kross and simple file operations made this possible.

Yes, and Qt is a real API and that's what we're binding with JSmoke...

>> Plasma is using QtScript as well, so yea I don't think KJS has much of a
>>  future.
> Thanks so there is no real reason to try and fix it.
>
> The problem I have at the moment is that QtScript in Kross has only some
> features of QtGui and KDE_UI pieces. What I would like to see is that a
> scripting fan could use features of QtCore and other modules of Qt or KDE such
> as akonadi and nepomuk.

Then load up JSmoke from your QtScript. It's a qtscript module.

http://gitorious.org/qtscript-smoke

Ian