Ian Geiser at SourceXtreme, Inc has posted the first 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 goes through the process of how to build a core script, add database connectivity and to add GUI control. Both developers and non-developers are encouraged to check it out.
Dot Categories:
Comments
Looking forward to the other articles, and being able to apply it to my desktop.
Also eagerly waiting for the ruby bindings to become mature :-)
Raph
We have some really exciting times for non C++ developers coming. With the rapid progress of the Ruby bindings, along with more cooperation in the PyQt/KDE realm, plus the stealth bindings for Java (check them out they are slick). There are no shortage of options out there.
Can you please pause this for a couple of years? I really want to learn C++, but with all these great tools there's no need. Please force me to learn C++.
;-)
I guess we could forbid you from using it. :-)
No, you can't. If you would, you would break the GPL! ;)
Only if HE would break the GPL, he would loose the right to use it...
"Also eagerly waiting for the ruby bindings to become mature :-)"
Well, try the version in the KDE 3.2.2 release - the were some bug fixes, and DCOP support added. I'd say it's pretty 'mature', in that it covers the complete Qt/KDE apis and the Smoke library it uses is entirely autogenerated. You can override virtual methods, use the operator overloaded methods (like + for adding QPoints for instance), and do pretty much anything you like.
I enjoyed the ruby-gnome presentation at FOSDEM, they showed how to build a UI with glade for a simple CD player interface in 30 mins. You could do much the same with the kde bindings, but using Qt Designer/rbuic instead of glade. They had a nice documentation browser - I would say that was the main thing missing from the equivalent QtRuby/Korundum dev environment. Alex Kellett is working on one called 'RubberDoc', and I'm hoping to extract the doc comments from the KDE headers and convert them to RDOC format.
-- Richard
Hey Richard, I've been watching all of your and other people's work with kdebindings, but I see almost no press of it. I think perhaps if you or other people would write short tutorials of it, like Ian has done with kjsembed, they would get a lot more attention. I would write them, but I frankly have no experience with most of the languages in kdebindings :-) (oh well, perhaps give me a reason to learn something like Ruby :) )
Yes, I agree (although I like the way Ian described the java ones as 'stealth bindings'). I rely mainly on Rich M.'s April Fools for press :)
It would be great if someone did do a similar intro/tutorial for QtRuby/Korundum - that would certainly raise the profile of the ruby bindings. And I think it would be an excellent reason to learn ruby!
Alex Kellett has done a great job at setting up the RubyForge site, writing examples and so on - but we'd find any extra help really welcome.
My problem is that I'm working on more than one binding, and I don't have enough time to do the other stuff - like telling people what to do with them/publicity/documentation and so on.
I'm thinking of doing some short blogs on kdedevelopers.org explaining what's going on in kdebindings. I particularly want to attempt to explain what the Smoke library is all about - some of our stuff like that and the quality of out autogenerated code puts us a long, long way ahead of any comparable project.
Well, I'm really looking forward to learning and doing stuff with Ruby when I get the time. Why is Ruby not used more widely, and why am I stuck with VB 6/VB.NET? Damn.
We should set up a site where everyone can post his KJSEmbed applications and discuss about KJSEmbed in general. I personally wouldn't mind seeing more KJS games along the line of invaders.js (http://tinyurl.com/yrr4m) ;)
Invaders? This whole thing is fantastic. I think you should post it to /.!
I wrote a space invaders clone to see what the ease of porting current javascript web apps to KDE would be. The results where amusing, although I cannot get past 7 invaders getting through :(
As for a slashdot post, feel free to.
screen shot for invaders is here: http://www.kdedevelopers.org/node/view/260
This sounds very cool.... however, I don't seem to have it on my Freebsd 5.2/KDE 3.2.1 system. It sounds like it comes with KDE?
You need kdebindings installed.. :(
(wish more distros and BSD variants split up kde)
any1 got a .deb for it?
they are in the works... the packager is trying to get them out asap.
Yes, I talked to him last week and he was testing things.
Hi Ian!
I've looked into KJSEmbed and I have to say I'm very impressed with the possibilities for KDE application development. Kudos on a job well done.
One thing I've very interested in is how to set up and use visual KParts with KJSEmbed. For example, I can't seem to figure out how to embed a KATE part or a KHTML part. I'm also curious about how to "KDE-ify" Qt Designer for use with KJSEmbed. Specifically, I'd like to know how to go about getting the kde default icons from the current icon theme so I could use the appropriate icons for things like File->open and what not in my menu items. The last time I tried this, it didn't seem as though KJSEmbed had the bindings to the appropriate Qt objects that I needed to do this.
Ideally, what I would like to do is be able to drag and drop a KHTML and/or KATE part from my Qt Designer pallet onto a form inside Qt Designer and tell my Qt Designer menu items to use the standard KDE icons where appropriate.
Would it be possible to put together a sample application that did something like this? Actually, I would be happy to do so myself if given the appropriate technical directions.
Thanks again!
David
Have you seen the exmples page?
http://xmelegance.org/kjsembed/examples/index.html
Yes, but I must be missing something. If I try to run the readonlypart sample application, I get the following:
QPixmap: Cannot create a QPixmap when no GUI is being used
QPixmap: Cannot create a QPixmap when no GUI is being used
QPixmap: Cannot create a QPixmap when no GUI is being used
QPixmap: Cannot create a QPixmap when no GUI is being used
kbuildsycoca running...
kded: WARNING: KGenericFactory: instance requested but no instance name passed to the constructor!
kded: WARNING: KGenericFactory: instance requested but no instance name passed to the constructor!
kjscmd: WARNING: addBindingsClass() KJSEmbed::KJSEmbedPart not known
kjscmd: WARNING: addBindingsClass() KJSEmbed::Bindings::Config not known
kjscmd: WARNING: addBindingsClass() KApplication not known
kjsembed: WARNING: findSignature: not supported type stackUnder(QWidget*)
kjsembed: WARNING: findSignature: not supported type stackUnder(QWidget*)
kjsembed: WARNING: findSignature: not supported type setActiveNode(const DOM::Node&)
kjscmd: WARNING: addBindingsClass() KHTMLPart not known
kjscmd: WARNING: addBindingsClass() KHTMLPartBrowserExtension not known
and then it dies.
I'm also confused how you would combine using a KHTMLPart with Qt Designer. It looks like this example builds the GUI itself which isn't what I want. I want to be able to use Qt Designer in addition to visual KParts.
Am I missing something?
David
because of how Qt designer and kparts work now, its impossible where impossible is possible only with a great deal of effort.
Any Kexi developers here? I heard that they had a KDE WYSIWYG designer that I (sadly) can't get to work currently. Any hope that that code could hook up into KJSEmbed and do what I want?
David
KFormDesigner is Kexi independent KDE-compatible Qt Designer replacement (under active development). By integration I mean you won't be forced to hack widget plugins to get KDE widgets to be visible (as it's the case with Qt Designer, or I am wrong?). You will be able to build KMainWindow-based aplication with all these benefits like KActions, toolbars XMLGUI, etc.. i think with just few mouse clicks :)
:)
It's all depenending on interest KJS (PyKDE, Ruby, etc..) developers when it can be integrated with particular bindings. It's not a solution for today, though. Maybe even not this year in a stable (API, implementation) form.
regards,
Jaroslaw Staniek
Kexi Project: http://www.kexi-project.org, http://koffice.kde.org/kexi
QT-KDE Wrapper Project: http://iidea.pl/~js/qkw
Shit, missing exec call in the example due to the change in semantics. Try this:
../../../kjscmd --exec readonlypart.js
I have to say JavaScript looks surprisingly elegant in your examples. This language was designed by Netscape? How does it compare to say Python?
Well, it is conceptually quite different because it uses a prototype based object system. It is better for embedding in KDE though as the interpreter is small and binding things is quite straight-forward (and will be automated when i get a chance to finish the code). There is also the advantage that the interpreter is often in memory already.
JavaScript wasn't actually designed by Netscape btw, they bought it from someone else when it was called LiveScript IIRC.
Good page about Java/JS/Live/ECMAScript's history:
http://www.oreillynet.com/pub/a/javascript/2001/04/06/js_history.html
That is very interesting. It's worth noting that a lot of the problems he refers to are with the HTML bindings, which is really a non-issue in the case of KJSEmbed.
So in other words yes Netscape created Javascript from its employees.
If you mean my comment about them buying it was wrong, then yes it certainly looks like it.
JavaScript a.ka. LiveScript was created by Brendan Eich at Netscape.
It is simple, interpreted, dynamic (e.g. functions can return functions), procedural and object-oriented.
Didn't another company make the mistake of embedding scripting languages in their OS?
I'm not downing KDE (since I've loved it for a long time now), but isn't this a sign that maybe it being taken too far?
KDE is hardly an OS. And considering how many websites are already using
Javascript that is run locally on the client, I think its pretty clear that
it's much more safe for web delivery of code than VB/VBScript ever will be.
This stuff is really exciting. Others are talking about rich, web-deliverable
GUIs as something that will happen in the long term, yet here we have the KDE
team using our framework to lay the foundations already. On top of that, it's
not just proof-of-concept hacks - you can already build local clients using
this stuff today!
yes, Att has had scripting on the os level for some years. i think 1972? to this date there have been no ill effects. you may have heard of it, its been called Unix.
I think you may be referring to scripting viruses and alike. Scripting is fine, as long as programmers and people are careful as to what external scripts can do. It is also amuch more powerful way of getting things done, and means that KDE applications can be much more integrated and useful together rather than standing by themselves. Fortunately, we don't have scripting hooked all over the place in an e-mail client like Outlook does.
Yes, scripting is more of a risk, but there are just some unbelievably bone-headed things Microsoft has done that have made people rather paranoid. Dealing with Windows everyday in a financial institution, I can speak with authority on the stupidity of Microsoft towards external scripts and security. They really just don't understand it at all. People elsewhere, in the open source world, do.
Scripting is no more of a risk than allowing users to run binaries. Between the fact that Unix has an execute bit (ie you cannot execute the file no matter what it is if its not set) and the fact we do not rely on file extensions for mime type identification we are much safer. Once you get a script in the mail, and copied it to your hard disk and then set it to executable the barrier for entry is high enough that automated virus like scripts are very hard to do. At that point you are better off looking for open ports to throw a buffer overflow into or beating up the user to steal their console.
In KDE land scripting is no more dangerous than running a binary program.
> In KDE land scripting is no more dangerous than running a binary program.
One small correction: It's often mentioned that Linux takes advantage (when we're looking at viruses issue) from that there are many OS distributions/versions that do things a bit differently and have binary incomaptibility. Thus, it's a bit hard to produce binary program that highly is binary portable (you'd need to link statically, you can't be easily architecture-independent, and so on).
OTOH, with scripting, these problems pretty much dissapear for virus writers. Of course, how nice, we have The Executable Bit[tm], so since there weren't Bash viruses on our boxes, other scripting engines won't make so much difference. :)
--
JS
...or python viruses, or perl viruses, or pike viruses, or awk viruses, or ... you get the point. this is nothing new folks...
as for the binaries, there is the fact of binary compat... but there are ways around that at least for the i386 arch's... but again the barrier is so high, its just not worth it... besides im sure i could take most of you with a baseball bat anyway ;)
Executable binaries on Windows....don't get me started. God I wish I could move away from Windows tomorrow, because there's a lot of sensible stuff in Unix/Linux based operating systems that I really want that could stop all of this tomorrow. The only problem we would have would be being careful what servers we were running, as that is really the only feasible means of attack and compromise, and the chances of that aren't that great as we do that anyway. What are we getting instead? Talk of shield technology and adaptive crap that will screen content!!
"Once you get a script in the mail, and copied it to your hard disk and then set it to executable the barrier for entry is high enough that automated virus like scripts are very hard to do. At that point you are better off looking for open ports to throw a buffer overflow into or beating up the user to steal their console."
Damn right, and that happens regardless of market share. Even if there were a handful of viruses that could exploit one or two things (a vast improvement) at least it could be isolated and the virus has little chance of propogating and spreading.
Is KJSEmbed comparable with XUL from Mozilla? Can you use KJSEmbed in your web applications? Or will Konqueror use XUL in the future for easier development of web GUI's.
I think this it's very important for Konqueror to have such a thing. I use TYPO3 and I cannot use it with Konqueror because it needs Mozilla/Internet Explorer for it's WYSIWYG editor. TYPO3 will have an API for it's WYSIWYG editor in the next version, so it would be great if it would be possible to implement a WYSIWYG editor with KJSEmbed.
kaxul is a proof of concept that is already in the works. developers are welcome =)
> I use TYPO3 and I cannot use it with Konqueror because it needs Mozilla/Internet Explorer for it's WYSIWYG editor.
I don't think that has anything to do with XUL.. it's probably because khtml doesn't support designmode or contentedible yet
geiseri,
are you planning for a "KJSEmbed" tutorial/talk at "aKaDEmy"?
(watch out for the "Call for Papers" at http://conference2004.kde.org/ coming out soonish... :)
Cheers,
Kurt
well see... if rich comes this year i may not get a chance too ;)
So I need kdebindings to use KJSEmbed, right?
Where is it (rpm) for SuSE?
I do not see it on SuSE's ftp, and not on KDE's ftp server.
With the idea of using KJSEmbed to 'save time' in development, do I have to spend time first to compile it myself? And probably without success, running into the reason (?) why SuSE has not made the rpm?