There are two different topics here, really: in-application scripting and application development proper.
Creating Applications Without C++
We have some great language options for people writing KDE code, and have had for a number of years thanks to the foresight and diligence of the KDE Bindings community. We owe them a debt of gratitude for these efforts, because as a result of them we can choose to write applications in Python, Ruby and other languages. For the sort of code that gets written in the vast majority of applications, the added overhead of these languages is a complete non-issue in terms of user experience impact.
The benefit is that people can write applications faster and with fewer errors, not to mention they don't have to learn C++ if their language of choice and expertise is Python or Ruby. That means that we could see more applications with fewer defects coming from a larger audience.
In 2009, we saw the first non-C++ application ship with the KDE Software Compilation: a printer configuration tool. There are many other great Python/Ruby KDE applications "out there" coming from the wider audience of people who write software with the KDE Development Platform. It would be great if in 2010 we can raise awareness of this and as a result grow our third party development audience as well as see increases in efficiency amongst some of our own application projects.
Now, there is some downside to divergence from C++ as a "lingua franca": it is harder for someone who doesn't know Python to contribute to a Python application. However, based on my experience in doing so, it's completely within reason. (I don't "know Python", per se, but I have contributed patches to Python applications despite that. :) This is in large part offset by the fact that we don't rely on the language itself as much as we rely on the great APIs that Qt and KDE deliver as our "lingua franca". Which is to say: a KFileDialog in any language is still a KFileDialog. ;)
In-Application Scripting
While having a multiplicity of languages and not caring particularly for the overhead of them is completely acceptable, and even comes with some benefits, in the application development arena, the landscape is a bit different when it comes to application automation, aka "scripting".
Such scripting encompasses a wide range of applications: from writing bits of glue in a spreadsheet to writing extensions for Amarok to Plasma widgets, in-application scripting can transform an application into a static black-box experience into one that can be easily extended at runtime by even novice users (by using scripts from other less-than-novice users) while still keeping the default user interface sane.
The choice of language here is probably a bit more critical than with application development. The choice should appeal to the widest possible audience, should be available (e.g. installed) on the widest number of systems and should (paradoxically) not include so much more functionality than actually needed that it becomes a management nightmare for the user. That last point is one that is usually learned by application developers the hard way by offering support for, e.g. Python scripting, only to find that some of the scripts written and being shared around require some obscure or version-incompatible bindings/additions/API extensions to the language making it much trickier for users of the application to reliably use scripts from a shared repository.
This is why in Plasma we have elected to support various languages (including Python and Ruby), but to also try and promote the usage of Javascript: it's included with Qt, it has a very very large user base and it is limited in scope allowing us to craft the scripting experience we want in a more reliable (for our users) fashion. This is also why at Akademy in 2007 there was general agreement amongst the attendees (some 50+ core developers were at this particular meeting, if I recall correctly) to promote Javascript as the preferred default for such applications, even when we also support other languages, such as Python and Ruby, as viable options at the discretion of our users.
In 2010, I think that such scripting is going to take a larger role than ever before in KDE software. The Javascript APIs for Plasma are really shaping up (some distributions are already shifting to it for management of Plasma Desktop installations and we're getting more questions about Javascript Plasmoids than C++ ones these days), Amarok 2 is really hitting its stride and the idea as a whole seems to really be getting more and more legs. Consider today's posting by Fred Emmott of a Javascript based Qt application testing framework: it allows recording and playback of interface interaction and application execution, all powered by QtScript for the automation.
This strategy, which can be seen being employed to great results in other hugely successful pieces of software such as Microsoft Office and Mozilla Firefox, can help us create more streamlined default interfaces with more options for our users in a manageable fashion. Combined with the increased traction we're seeing right now, this could be one of the signature shapers of KDE software in 2010.
We have excellent tools (QtScript as well as Kross) that make it really quite easy to accomplish it in our applications. What are we waiting for? :)
(This article is part of the "Key Quests for KDE in 2010" series)
11 comments:
Very nice article, Aaron.
One word of warning about Kross (you've basically already said it, but it's worth emphasizing that again):
While Kross is a great technical achievement, and it has its use cases, it also comes with one giant drawback:
Dependency Hell
If you ever want your apps to run on Windows and Mac, then please consider that it's a major hassle for these users to install Python, Ruby, Lua, etc (not to speak of Bash!), plus a number of libraries that the scripts pull in.
In that light, I would really recommend to stick to QtScript (JavaScript) only.
Less comfortable for the devs, but much more comfortable for the users. A trade-off that's worthwhile.
Regards, Mark.
One thing I'd point out to developers is that it is often very easy to code small parts of an application in js even if you aren't planning on exposing the scripting facilities to users. An example in KDE is the calculator krunner, but I've also found the same thing useful in a large number of other small tools.
Does plasma use kross, or implement its own bindings?
In kexi reports i originally started with qtscript only, then re-wrote it to use kross to gain multi-languge ability.
@Mark, kross languages are plugins so there should be no problem limiting which are distributed with windows right?
@Piggz:
Unfortunately, that doesn't solve much of anything.
If users download scripts from kde-apps.org (GHNS), what happens then? Dependency Hell...
Regards, Mark.
One solution would be to just distribute Ruby/Python/whatever packages as part of the base KDElibs/runtime install on the other platforms. What's the downside? A few extra megabytes?
@Mark, I must say the objection to kross by considering that two of its engines don't work (at the moment) on windows (I have ruby running nicely on Mac OSX) is probably one of the most silly I have ever heard. Firstly, I don't like the idea of going for the lowest common denominator, and secondly, if there is no demand or pressure to have a feature, a library working on a platform, because no one is using it, well it will never be available on Windows. The right things to do is to use the features you want to use, and when there is demand for it, someone is going to come and do the hard work on making the dependency available on your system.
@Cyrille:
Well, if you want to do that mistake, then go ahead :) Noone is stopping you. We decided not to repeat this mistake (we made it once, that was enough) in our application, and now we all think it was for the better.
You have been warned, however. A smart move, this isn't.
Regards, Mark.
@Cyrille: the problem isn't even just ensuring that python and/or ruby are available. that's just one dependency. what often ends up happening is that developers using those languages will end up pulling in other libraries and feature sets for that language.
CPAN is awesome for perl, but it makes deploying perl apps slightly more difficult. for an application, however, this pain is completely manageable.
when it's due to a script that a user downloads, e.g. via GHNS, it becomes a real nightmare due to having to automate the fetching of those additional libraries, assuming they exist at all, and making sure they are feature/version compatible with the script.
iow, this isn't an issue of the application (e.g. amarok) defining the dependencies, but the scripts that third parties write that start extending the dependency requirements in unforeseeable / uncontrollable ways.
the user just wants the extensions to work, they don't care why it doesn't.
by "boxing in" developers to a well contained set of bindings without random external dependencies, this issue is mitigated.
it's a nice bonus, as well, that Qt comes with an ECMAScript interpreter which means that if your Qt app is running, you have QtScript as well. (well, technically i think you can disable it, but.. yeah :)
@Rich Moore: yes, i think there are many more unexploited areas for scripting in our code. i'm hoping 2010 is a year we start to fill more of them :) keep leading the way for us to follow in!
@PiggZ: i think that there are areas where Kross is indeed a great fit. for a database application like Kexi, i think it makes a lot of sense, in fact. why?
well, for one, database apps tend not to be widely distributed to a random audience like plasmoids or amarok extensions are. they are generally written for a specific environment/audience, so the dependency issues don't come up so badly if at all.
furthermore, given that it's something of a specialized development environment (i used to do DB app development using tools like FoxPro back in the 90s :) it is really nice to have the option as a developer as to what language to use to write your application.
so in the case of kexi, i see it really as having more in common with application development than in-application scripting. as such, i think kross is a great fit for kexi.
@Mark
I'd prefer C++ above EcmaScript...
Sorry, but scripting-languages were made to make developers' life easier and not to enforce some safety. I prefer Ruby, somebody prefers Python, and it will make applications better when developers can use their favourite languages.
Let us wait for QtScript, C#, Scheme and Falcon for even more possibilities. :)
Warning about Kross:
It's much less powerful than real bindings. Look at the Ruby and the Python binding: They provide the full API and plugins get loaded using k(ruby|python)pluginfactory. You load a C++-plugin loading (Ruby|Python). Kross- and C++-plugins can't get loaded in the same way. Those pluginfactories are simply the most powerful way.
@aseigo
You should mention Smoke. It provides the features you need to embed C++-objects into scripting-languages in an efficient and flexible way, without Qt's runtime-introspection.
Jonathan
@TheUser: i agree with what you say in the context of application development, as state in the blog entry.
the differences start appearing when using it for widely peer-to-peer distributed extensions. at that point, the multilanguage-every-extension-and-its-friend approach tends to break down. (with some notable exceptions; see the discussion about kexi above.)
this has been borne out through experience, such as what Amarok found. this was not something to do with Amarok, either, but rather the emergent properties of a large community writing scripts, sharing them with each other and everyone expecting (reasonably) for everything to Just Work.
and yes, Smoke is a very powerful and useful tool as well. :) we'll likely be offering Smoke generated JavaScript bindings for a "full bindings" option in Plasma (and iirc Amarok is looking to use them in a similar way as well).
oh, and to make it clear, i'd probably never want to write a full application in JavaScript. i'd much rather use Ruby or Python for that :)
Post a Comment