We're regularly getting questions about creating scripted Plasmoids from new people showing up who are trying (usually successfully) to make new stuff that rocks in languages other than C++.
Yes, we have built it .. and now they are coming. First we take Manhattan, and all that...
There are, however, two things I feel particularly guilty about: our lack of comprehensive documentation for the scripting APIs and our lack of tools to help people writing Plasmoids. To that end, we started work on a content creation tool we're calling "PlasMate". The name comes from the idea that it will be your friend and partner ('mate') when making things for Plasma. Cheesy, yes. Corny, yup. Therefore just about right. ;)
The idea behind PlasMate is to give people a way to start creating things without worrying about anything except making their bits. It hides the whole metadata.desktop thing, the package layout details, making a Plasmoid package (aka "zipping up the directory"), uploading (and eventually forking other people's) content and even that whole pesky "saving and loading" thing.
Like Qt Creator, PlasMate starts up with a welcome screen that lets you spend your first click deciding what you want to do. Pick up where you left off on that widget? No problem, one click. Start a new Plasmoid? One click. New DataEngine? One click. Load an existing project it doesn't know about? Ok, a couple clicks. You get the idea. Eventually you'll also be able to wander through the online Plasmoid warehouse and pick someone else's Plasmoid to start working on.
As you edit a Plasmoid, you can see a live preview of it and even tweak its environment by doing things like changing the form factor or screen location. When you reach a "good" point in development, hit the "Create Save Point" button (or whatever we'll eventually end up calling it) and then continue working. Messed something up? Go back in time to a previous save point.
We will provide starting templates and even some tutorial like examples to start from, and relevant API documentation will be integrated right in.
The focus on "fast and streamlined" comes at the expense of some flexibility. You won't be using PlasMate any time soon for creating that next killer C++ KDE application. It isn't meant to compete with KDevelop or Qt Creator, and it uses as many components other people have written (such as Qt's SVG renderer and KDE's Kate editor component) to keep the code base itself small. This is all OK, though, because the point of PlasMate is to unleash people from the complexity of a full IDE or the "now what??!" of firing up KWrite/Kate/vim/emacs and staring at a blank text file.
In its current state, PlasMate can start new projects and continue previously started ones. It shows the contents of a Plasma::Package and can edit text files, .desktop files (with a custom form editor), etc., and has a little previewer for Plasmoids. We're busy sewing the whole thing together still, and the UI is still not anywhere near final (ergo the lack of screenshots; I'll share when it's a little closer to somewhat-cooked versus the raw state its in now) and we have things not even started to be touched yet such as integrating a previewer for DataEngines (basically stealing code from plasmaengineexplorer, I imagine).
There is code, though, and there are at least four of us working on various bits of it (Richard Moore, Riccardo, Artur and myself) and we've laid down a little over 2,000 lines of code for it already, mostly during Tokamak II.
The goal is to release it along with KDE 4.3, and maybe even do a few preview releases between now and then. We want it to eventually bloom into a full point-and-click wonder including Plasma UI builder and interface creation automator. While it was never my original intention back in the day, I now have the ridiculous goal to "kill flash" and that means having creation tools. PlasMate is the start of that, and while it almost certainly won't kill flash (though hopefully it will dislodge it from certain types of projects that really should be using something more sane) that goal gives us something to aim for in terms of functionality.
(By-the-by, having goals that you can't reach but which you use means to set direction is an interesting technique when used appropriately. As long as you're realistic about not reaching the actual endpoint described by the goal but craft it in such way that it provides a meaningful journey along the way ... it can do wonders.)