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

[Richard Dale]

On Sunday 28 February 2010 01:19:54 am Andreas Marschke 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"?
> 
> > 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.
> 
> > 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.
> Is there a way to influence kross there to add these modules or will I have
> to add bogus objects that will be added in case somebody some time in the
> future wants to use it.
It you just use kross for non-gui based scripting it works well. Maybe it 
should have some simple standard dialogs too. 

But once you start to want to use kross with GUI's, then that isn't what it 
was intended to be used for. Using kross like that, where do you stop? How 
many Qt and KDE modules do you support? How many external Ruby, Python libs do 
you allow users to use?

A common problem with supporting people using the QtRuby bindings is that they 
want to use a Ruby library instead of a class that is built into Qt. So they 
use 'open-uri' instead of QNetworkRequest,. Then they report to me that QtRuby 
doesn't work well with native threads and it is difficult to coordinate using 
'open-uri' with QtRuby. So I tell them they should use QHtttp or KIO or 
QNetworkManager instead which all integrate well with the Qt event loop. But 
frequently they don't want to do tha, and so best solution is to use QProcess 
to start a sub-process which runs pure non-Qt ruby code and communicates with 
the top level Qt based process via QProcess. Well that might be ok for a 
standalone app where creating sub processes is ok, but for a scripting 
extension to a C++ application it is a bad idea.

So the difference between the JSmoke bindings for QtScript and QtRuby for Ruby, 
is that there really aren't many stand alone libraries for QtScript like 
'open-uri'. People using JSmoke will always have to use the 'Qt-way' of doing 
things.

For implementing scripting in an app like Amarok this is actually really 
useful as Ian has pointed out. I personally think that if you want to go 
beyond basic non-GUI scripting with kross, then the Amarok approach is a 
really good model. They don't allow you to load any QtScript module, only a 
set of about five of the Qt modules. They expose some 'standard objects' in the 
scripting environment like a 'Player' object with methods like 'start()', 
'play()' and so on. Then there is a dialog in the settings options for 
downloading and installing new scripts (using KNewStuff?). The whole thing 
feels cohesive and elegant to me, and users have written some very powerful 
scripts, such as a complete web server interface to control Amarok remotely.

So although I actually work on QtRuby as well as JSmoke, I think for a lot of 
cases such as app extension scripting it is better to stick with QtScript. 

For stand alone apps or plugins, then the Python, Ruby, C# etc bindings are 
really good and make total sense.

-- Richard