Perusing through the Plasmasphere as 4.2 looms seeing what needs attention, I had my gaze drawn towards the JavaScript ScriptEngine by Chani. The everything-and-the-kitchen-sink JavaScript API is still in playground, so that won't be there until 4.3, but the basic API was there in kdebase and it generally worked. For certain values of worked. There was much left to be desired.
We've added a number of things to it to get it into shape and feature complete in time for 4.2 so people can actually start using it. It's pretty rewarding to see how fast and general painless working with QtScript can be.
Perhaps just as important, I've also begun documenting the API. Miracle of miracles, documentation!
The Simple JavaScript API will be shipped as "unstable" in 4.2, meaning that I may make changes to it in 4.3. This will allow those of us who care about these things to work with people who would like to use such things and round off the corners between now and 4.3. This is much like how we didn't provide binary compatibility guarantees for libplasma until KDE 4.2. At least with things like JavaScript, it's a lot more flexible. =)
However, I am not a skilled JavaScript developer. I don't work with JavaScript day in, day out and so I'm not familiar with which idioms would make the most sense to those who do. For instance, today I run into this simple question: Is it more "natural feeling" in JavaScript to have onFormFactorChanged or formFactorChanged? I know that the former is used in web page APIs (onClick, onLoad, etc.) and that the latter is a bit more C++ (though even there we do it slightly differently, which a constraintsEvent method that gets a set of or'd flags). Right now I'm going with the onFormFactionChanged style, but that's purely a naive gut-feeling-and-a-little-knowledge-of-JavaScriptbased choice.
So if you are someone who works with JavaScript a lot, please find me on irc.freenode.net in #plasma and let's talk. I have questions, you probably have answers. My timezone is GMT-7, so keep that in consideration if you try and track me down. ;)
Also, we'll be looking for people who would like to do simple to medium complexity Plasmoids in JavaScript once 4.2.0 is out. You'll be our guinea pigs and if you do your work alongside us in #plasma you'll have the chance to help improve the Basic JavaScript API and even test the Advanced version when it becomes available.
Saturday, January 03, 2009
Subscribe to:
Post Comments (Atom)
7 comments:
Hi Aaron, Since I am working as a full-time webdeveloper, I'd love to test out the JavaScript engine. Honestly, I am desperately waiting for it since I am not too familiar with C++.
Drop me a line when you're done.
Hi Aaron, I'm an experienced JS developer, I do it for a living and do have enough spare time to help improving the API, I've also a C/C++ background and enough knowledge of QT to understand how the API works under the hood and what can/can't be done.
I've tried to contact you on #plasma but the guys there told me it was better for me to leave a comment on this post...
Just let me know if I can be of any help ;)
federico[dot]lox[at]gmail[dot]com
Aaron---
To answer a specific question you raised: JavaScript event handlers are associated with an object. The event handler is a property of the object in question, which is then assigned a pointer to the appropriate function.
Now as a JavaScript coder, I've run into several situations where things are handled differently across browsers, especially event handler assignments. Since, however, Netscape begat JavaScript, and Mozilla begat Netscape, and Mozilla also begat Firefox, I'll use Firefox's interpretation.
Here's one way to handle it:
object.onsomeevent = function (theEvent)
{
// event handler code here
}
This could also be valid:
function OnSomeEvent (theEvent)
{
// event handler code here
}
object.onsomeevent = OnSomeEvent;
My experience is that the event handler can only be defined for an instance of an object.
Note also that the object's event handler is neither CamelCase nor camelCase, but is all lower-case as is the style for an XHTML element attribute.
For a fairly exhaustive reference for the JavaScript API, might I suggest the JavaScript Kit.
Hope it helps!
Both methods posted by henry are identical. One just uses anonymous functions while the other does not ^_^
From what I understood of your post, here is a simple suggestion: follow Qt4/KDE styles. when prototype chaining or functional approach helps, use it instead. this keeps things familiar. But I would have to know a little bit more about the questions you are having.
Btw, my knowledge of JS (both inside and outside the browser) and it's specs is quite decent.
My jabber: tsilva@jabber-br.org
Hi Aaron, Since I am working as a full-time webdeveloper, I'd love to test out the JavaScript engin
Not Needed
If you are going to use the default object you can use the prototype property as a class-esque design. Like so:
Object.prototype.onSomeEvent=function(theEvent)
{ /* Event code here */ }
Prototype also works with any object and you can make a class like inheritance scheme by assigning another class instance to the prototype property of an object.
I would like to contribute by coding and debugging. It sounds like you may be inventing the wheel again if you are writing your own javascript engine. I have the time to write a javascript engine and/or write a coherent and consistent javascript KDE API wrapper. I'll have to get my head around the efforts to date. In the mean time I'll get started on a javascript KDE API using Mozilla's javascript library.
Post a Comment