FireTcl
https://sourceforge.net/projects/firetcl/
FireTcl is a new way to develop desktop applications using web technology and Tcl.
It embeds a Tcl interpreter into Firefox.
FireTcl gives you the possibility to eval Tcl code in the user interface thread or in a browser worker. The Tcl code evaluated can execute also javascript and interact with the DOM.
The advantages of using web technology are:
AMG: How does this compare with the Tcl/Tk plugin?
FireTcl: It seems that the plugin uses Netscape Plugin API. I use a very simple approach: I use the XPCOM component js-ctypes for interoperability with the interpreter. Also I use coroutines for emulating interactivity: coroutines saves the state of an evaluation and returns a javascript code to eval or a signal indicating success with a return value or error with information about the error.
Behind the scenes js-ctypes uses the library libffi. This means that each time that a user makes a call to Tcl all passed arguments from the browser are converted from the native form to a C type value. And the returned value from the call is converted from a C string to a javascript string.
What are the advantages of this approach?
::FireTcl::eval_javascript {alert("hello world!")}
Another possible approach for giving support to the other browsers (Chrome, Internet Explorer,...) is to uses a local server and make all the requests for Tcl evaluation to this Tcl server. PHP Desktop uses the same idea [L1 ]. They use Mongoose as the web server.
One possibility is to use a Tcl websocket server for doing efficient calls and for bidirectional communication.
This other approach using a local server is a complement to my approach for giving support to the other browsers. But FireTcl is a little bit more efficient.
bll 2015-8-22: XPCOM is on its way out apparently. https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
FireTcl 2015-9-4: After 15 years of XPCOM and XUL, firefox decided to deprecate this technology. I don't know what will happens at the end because the main strength of firefox is its potential for building extensions, and a lot of users disagree with this new direction of firefox. There is a lot of complaints. It's possible that firefox will support js-ctypes in its new API WebExtensions because js-ctypes doesn't depend directly on XUL, or perhaps will be possible to build another efficient bridge using the new API, because for example they guive support for the system/child_process Add-on SDK module:
https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process
The future is uncertain. Anyway I decided to fork this project and build another bridge using websockets. The browser will send Tcl code to eval to a local server through websockets. This solutions works for all modern browsers and it won't be never deprecated, because websockets takes part of the new HTML5 API and it's a solution to an old problem: bidirectional communication to a server (for example, for chat applications). Also XPCOM will work for at least 12 months more. I will try to provide the same API for this new bridge. This way the same code will work for both bridge. This will make the transition easy.
I want to add here the apocalyptic message of the book of mozilla (writte "about:mozilla" in the URL bar of firefox):
"The twins of Mammon quarrelled. Their warring plunged the world into a new darkness, and the beast abhorred the darkness. So it began to move swiftly, and grew more powerful, and went forth and multiplied. And the beasts brought fire and light to the darkness."