So over the last few weeks I have started work on the new KJSEmbed that will be in KDE 4. In a change of heart that is an entirely different blog all together I have decided that I will push to have KJSEmbed in the core of KDE 4.
My goals are to make KJSEmbed able to be natively handled via KParts and bindings available automaticly inside of appliactions. I hope to allow for KJSEmbed applets in Kicker, KDesktop and elements of the Konqueror file browser. More will come on this later as I have a few more examples, and when KDE starts the Qt4 migration.
Currently I have simplified the bindings system and made them much smaller and faster. There are basicly 3 stages of bindings. 1) Value bindings - Basicly anything that can be handled by a QVariant. 2) Object bindings - These are pointers that cannot be supported by QVariants. 3) QObject bindings - These are just special Object bindings that dynamicly expose properties and slots. Unlike the current version KJSEmbed will have the ability to add any type of binding at runtime has been added. This will make extending KJSEmbed much easier so we can ship a much lighter core. The goal is that KDElibs could contain a very simple core KJSEmbed and the extensions could lie in the KDE bindings. This would allow for a base functionality and scripting layer to be added to every application in KDE. This could bring some very powerful tools for applications like KWord and KDevelop, as well as quanta. Using KJSEmbed as a lightweight layer we could also do some very remarkable things with applications like KControl and smaller KDE applications. KJSEmbed gives us a very fast, portable and flexable way to build smaller KDE applications. One powerful thing about KJSEmbed is that it basicly is "glue" that holds C++ objects together. This allows us to do the dirty work of component development in C++ and very easily use KJS to hold these different components together. The future gets even more exciting if we have KParts support for loading KJSEmbed components, as then they can transparently mix with our other C++ applications as first class citizens.
I already have hacks for KDE 3.x that have kicker applets, kdesktop applets (aka superkaramba like) and konqi sidebar plugins that use KJSEmbed. These are horrible hacks, and require some stupid BIC changes so they wont see the light of day until KDE 4. Needless to say I have some exciting dreams for KDE 4. 
Syndicate Blogs
excellent...
(the title is to be read in form of Mr. Burns)
> KJSEmbed applets in Kicker
there will already be at least one applet (the clock) that uses KJSEmbed for sure in Kicker4 (codename: punter
... and the plan has been to offer an applet container that simply provides KJSEmbed bindings for the applet interface. will be rather trivial once the applet class is associated a bit better with kicker and reworked for sanity.
as for kdesktop, the plan there is to more or less get rid of it and merge it and kicker into one application. there's really no need for them to be separate processes, and with all the cooperation they already do (background, icon placement) it only makes sense.
so KJSEmbed "panel" applets could just as easily appear on the desktop as well. in fact, if all goes well, applets will be able to appear on panels, the desktop or "floating" without the applet needing to know much about what is going on.
anyways, i'm happy to hear about your intentions with KJSEmbed. i will support them all the way as i think that this is an important thing for KDE.
in fact, i'm hoping that in KDE4 we will see KJSEmbed become a first class citizen for in-application scripting and lightweight prototyping and Korundum a first class citizen for "heavyweight" prototyping and full-on application development.
we can all dream, right? and if you believe long enough and hard enough, your dreams will come true. (a cookie to the person who places that move quote
actually
...in nonbeta there is a KJSEmbed kicker applet one already. i think it might actually be called punter
as for prototyping, I have actually worked out some scripts that will convert a KJSEmbed app into a C++ app in a mostly automated fashion. unlike pretty much every other language out there Javascript can reasonably covert into Java or C++. This gives it a very attractive position when it comes to prototyping. Nothing sucks worse in the windows world than doing a prototype in VB, and then having to throw EVERYTHING out when you convert it to something else...
I think your work could benef
I think your work could benefit a lot in the area SuperKaramba tried to solve, making coding little desklets very easy and eyecandy. Do you know if KJSEmbed could be lighter than the Python implementation of Karamba?
Also, there is lot of stuff in applications that can be solved with small scripts. If plugins changed the way to design software (thinking in extensibility from the beggining), I think scripting can do it at a new level, with more power and less setup time.
Business applications for example are a special case where requirements are more stricts than common apps. If Amarok doesn't support a feature I will not care too much and probably wait for it. But if I need a small feature or workflow in an accounting application for work, scripting could do it very well and requires no setup time (compilers, buildsystem, etc). FacturaLux, a spanish small ERP system is a very good example. The core is very small and most of the business specific part for each module is done trough scripting and forms/reports descriptions.
much lighter
yes, KJSEmbed is much much lighter than python and any of its scripting brethren. I am also working on making it lighter. KJS may not be lightning fast, but it is not going to be a bottleneck in your app unless you do something insane like try to solve a PDE with javascript.