Ian Geiser at SourceXtreme, Inc has posted the second in a series of articles on development with KJSEmbed. KJSEmbed is the KDE JavaScript engine with bindings for Qt/KDE.These bindings allow people to create scripts that can tightly integrate into KDE quickly with simple JavaScript. This article covers how to use the DCOP API from KJSEmbed and sports a simple demo script that shows off how to use this API. This article covers the bleeding edge version of KJSEmbed from CVS because of new features that where added soon after the release of KDE 3.2. The goal is to give people an overview of the new technology and to allow developers to become aware of the new scripting options. Both developers and non-developers are encouraged to check it out.
Automating Your Desktop with KJSEmbed
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
I’m a C# developer (.net framework) and I’m in the process of learning C/C++ because I’d like to develop apps on linux.
I’m just curious what the speed is like compared to C++ QT apps?
On a decent machine (say 800MHz+) with a reasonable amount of ram would you notice a speed difference compared to a natively compiled app (i.e. fat client w/ database backend)?
The speed of a Javascript-based app really depends on what you are using Javascript for. Consider Javascript to be sort of the “glue” between various elements, while the elements themselves are written in C/C++. In other words, don’t use Javascript for processor-intensive tasks, but for such things as simple app flow, user event-handling, etc… If this is the case, then there is no reason an app like this cannot be fairly snappy.
For example, I regularly develop apps in Mozilla/XUL, using Javascript to handle the user interactivity. My ‘serious’ processing tasks are done behind the scenes in other languages, but Javascript handles everything related to user interactivity. Again, as in the case of Qt above, all the actual presentation is done by compiled components, so Javascript’s really does very little, but simply provide a light layer of communication between the other two layers of the system.
Viewed in that light, I think KJSEmbed looks like a very promising project. In fact, it looks pretty much like they are borrowing a page from the Mozilla book, as you can see with the *.ui files in the examples (UI described in XML, scripted in Javascript).
I guess I should clarify: in your example above (fat client w/ database backend), if you are using the built-in KDE-database bindings, and keeping most of your business logic in the database, then I think your performance hit would be fairly minimal. I guess app start-up time would be slower (the first time, until it is cached), but otherwise, the real load is being handled by the database and the Qt native components.
Your answers are pretty true for kjsembed too, though the JS itself is reasonably quick. For example there is no problem handling mouse and paint events from scripts.
BTW Since you’re interested in XUL, you might light Kaxul which uses kjsembed to allow you to run XUL code with a native KDE gui.
Thanks for the tip! I’ll check it out.
While I have you here, I’d like to ask another question or two: Is the JS engine in KJSEmbed based on the Mozilla JS interpreter? Is it a complete implementation of JS 1.5?