I've moved the JavaScript Plasma ScriptEngine and the plasmapkg tool (which takes care of install, upgrading, uninstalling and listing things wrapped in Plasma::Packages) into kdebase-runtime. plasmapkg was being used by the PlasmoidPoackage in libplasma, so that one was almost a no-brainer, but the main reason for the move was so that Plasma using apps can take advantage of using Plasma::Packages for their post-install data add-ons and JavaScript for Plasmoids and Runners (in 4.4 I'll be adding DataEngines).
It was the Amarok team that asked for better access to these tools, which up until this point had been hiding away in kdebase-workspace which really isn't an acceptable dependency to carry for a non-workspace application.
I'm really excited about the growing usage of scripting, and JavaScript in particular, to extend applications at runtime. JavaScript has the combined benefits of being fast, lightweight, dependency-free for Qt and KDE using apps (it's already in the dependency chain), easy to add to your app and easily secured.
If your app needs to be extensible and you're thinking of providing a C++ plugin interface for it, think hard if you can't "get away with" a JavaScript based one instead.
I'm also noticing a lot more Python and Ruby coders appearing around KDE and working either full apps and/or Plasma addons. This is also a nice trend: Python and Ruby are, in my humble opinion, terrific and for many situations perhaps even the preferred path compared to C++.
Subscribe to:
Post Comments (Atom)
11 comments:
I guess this has been asked before, but I never found an answer.
I really like the scripting extensions with JavaScript. I do wonder with the python and ruby bindings... I can see their benefits for existing code (e.g. company frameworks), and on the other hand I wonder if we wouldn't risk ending up with a DE which requires a lot of interpreters running in the background? What are the thoughts about this?
Can you write a fully-fledge kde app in javascript with bindings to kio, kparts, etc or you need to bootstrap it into some kind of c++ code?
@Diederik: for stand-alone applications it's negligible next to the overall requirements and pays off in terms of developer reach and productivity.
but for application extensions, the concerns you raise are exactly why we encourage javascript.
that said, i'm not about to tell people "no you can't!" so people who want to have done Plasma::ScriptEngines for Pythong and Ruby and people enjoy using them. that's all good :)
for strategic programs / initiatives and default components, however, it will be a javascript world.
python and ruby can rule the roost in app devel :)
Currently it seems that Google gadget support in Plasma depends on mozjs which prevents the inclusion of this feature in Kubuntu (see https://bugs.edge.launchpad.net/ubuntu/+source/google-gadgets/+bug/314778). Is there any chance to break this dependency?
Just out of interest: How do you interpret these javascripts? KHTML's KJS? WebKit's JavaScriptCore? Or is it indeed QtScript you use here?
Has any thought been given to moving the more stable/well-maintained bindings (Ruby, Python I assume) to kdelibs? I suspect people would use them more if they had to worry about distribution issues and suchlike less.
p.s. trying to post on blogger with one account when you're logged into gmail with another is still a nightmare from hell. (i thought google was supposed to be good at this?)
@Andre: In Plasma we use QScript for the JavaScript ScriptEngine. However, the web plasmoids, which are a mix of HTML and JavaScript, run in a WebKit context. Most Qt/KDE applications looking for JavaScript based automation will likely opt for QScript as it has excellent integration with the Qt API.
@illissius: "Has any thought been given to moving the more stable/well-maintained bindings (Ruby, Python I assume) to kdelibs?"
kdelibs is for compile time dependencies only. kdebase-runtime is for runtime dependencies and is a required package for KDE applications. so these ScriptEngines, which are runtime not compile time dependencies, belong in kdebase-runtime which can be relied on to be there and which is already a dependency for a KDE application.
that said, i'm open to the Ruby and Python engines also ending up in kdebase-runtime depending on interest, demand and dependency logistics (they depend on kdebindings, which the JavaScript ScriptEngine does not).
Heh. I didn't mean the ScriptEngines. I meant the [i]actual bindings themselves[/i]. Smoke, Korundum, etc. Apparently that's a crazy thought?
ah, the actual bindings themselves. i'm not sure there'd be much to gain from that, other than making it really hard to do bindings for things not in (or under) kdelibs :)
we'd end up with a set of bindings in kdepilibs as well in that case, for instance...
@J: that's up to the google gadgets project, not us.. sorry :/
So I don't know if you notice new comments to week-old posts, but I wanted to elaborate a bit on my thoughts re: bindings.
Apart from some of the technical issues -- difficulty of integrating with C++ code (there's an encouraging SoC project on this front), occasional C++ ugliness leaking through, speed -- I think some of the major factors which could be holding back wider adoption of the bindings are not-so-technical.
Basically, they're all second-class citizens next to C++. They simply don't have (remotely close to) the same level of commitment and support. You can rely on the fact that if you write your application in C++, it will work and it will continue working, because it's, well, the default, and everything is written in C++. It can't break because if it breaks, everything breaks. You can't rely on that for the bindings. There's no guarantees. You just kind of have to hope that the bindings will continue to be maintained and stay in good shape, and that distributions will package them correctly and distribute them for you, so that users can run your application.
Case in point: I wrote a small game in QtRuby a few years ago. When out of nostalgia I recently decided to try it out again, I discovered that (a) Kubuntu no longer even ships KDE3 Ruby bindings (thank god I only needed Qt), (b) the Qt bindings themselves were very buggy. I had to make significant changes to my code to even get it to run again, and even then trying to use some of the functionality resulted in crashes. Lesson: If you want your application to stand the test of time, write it in C++.
I think including the bindings directly in kdelibs, and perhaps having a couple of things in kdebase use them, could go a long way toward improving the situation. For one, developers could rely on the fact that if a user has KDE installed, they also have the bindings installed, and there are no separate distribution issues to worry about. They could be much-better assured of the bindings actually working. This way, if something broke, it wouldn't just be Richard Dale's problem -- it would be everyone's problem, and it would get fixed, and developers could rely on the fact that this would happen. (Merely compiling doesn't imply working, which is why I also suggest using the bindings for some of the important bits in kdebase.)
Your point about "making it really hard to do bindings for things not in (or under) kdelibs" is a good one. I don't know if the bindings are entirely monolithic -- if they are, then I guess there's nothing that can be done, and the current situation will just have to be lived with. But if they aren't, then I think having the Qt and kdelibs bindings in kdelibs, the kdepimlibs bindings in kdepimlibs, and so on, would be exactly the way to go. If you want the bindings to be first class citizens, you have to treat them as such, and anywhere where people can expect that C++ will work, they should also be able to expect that the bindings will work.
(All of this is assuming, of course, that you want to see wider adoption of the bindings for applications. Plural you. The only reason I'm posting this here, I guess, is that it was convenient and also somewhat spontaneous.)
Post a Comment