FireTcl

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:

• Many important companies has their product web-based. This translates to more pressure to add more features and new standards to the web. Internet is evolving fast.
• Nowadays browsers are very well equipped, and make abstractions of technical details and differences between operating systems. It gives you a lot of possibilities out of the box: rendering of different image formats, a canvas for 2D and 3D drawing, bidirectional communications with the server, peer to peer communication with other browsers without any intermediary, video and audio players, an API to store persistent data,...
• Almost everyone with a personal computer has a browser installed. Browsers form part of everyday life of people for communicating, entertainment, research, business,...
• There is a lot of web experts around the world and it's easier to hire.
• A big community. This means a lot of libraries for code reuse, tutorials and resolved questions on internet.

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 library 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?

• It's very easy to maintain and to understand. This point is important for a long life project.
• The user don't compile nothing. The only requirement is the dynamic library to Tcl.
• It uses a library that seems that firefox will always give support: js-ctypes
• The user can eval Tcl on a worker. And there is no requirement of a Tcl with threads enabled, because the thread library is not used.
• It works for all platforms with a firefox and a Tcl 8.6 interpreter
• You can call javascript and manipulate the DOM. Example:

          ::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."

FireTcl 2015-11-7: I have just released FireTcl 4.0.1 This new release guives support to a solution using websockets for Tcl code evaluation on a server.

FireTcl 2015-2-8: I released FireTcl 5.1. The main new features are:

 - multiprocessing remote interpreter. Threads are not more necessary
 - remote workers on the server
 - evalute tcl scripts passing parameters
 - browser detection
 - powerful configuration file
 - debugging tools: tcl editor, firebug lite and js console of firefox
 - independence of the path of the projects. The only requirement is to add the script boot.js in index.html
 - support for clipboard added