March 2017
Mo Tu We Th Fr Sa Su
<< >>


Screenweaver HX

Posted on Jun 11 2006

Yesterday was released the first Beta version of ScreenWeaver HX. SWHX is a simple and powerful way to create Flash Desktop Applications.

For several months, I could see growing interest for Rich Desktop Applications using Flash as the UI. There were several popular projects already, like Zinc and the original ScreenWeaver, but most of them were just giving access to a fixed number of system features, and it was either not possible or not easy to add DLLs to get more features.

When working on Haxe Remoting, I could experiment with the new Flash8 ExternalInterface API that enables communications between Flash and Javascript in the Browser. There are some major problems with ExternalInterface and I agree with the author : ExternalInterface is broken for an out-of-the-box usage. That's why an additional serialization layer is needed to bypass the EI quirks. In both Haxe Remoting and SWHX, we're using some Haxe serialization to only pass strings between the two sides of the EI, which is greatly simplify everything.

In particular, it means that we didn't have to implement all the XPCOM stuff in SWHX. This resulted in less code, optimized for a particular usage. It of course somehow "force" the user to use Haxe Remoting to communicate between the System and Flash layers, but that's actually better since a lot more stable than "plain old" External Interface.

By the end of April I contacted Edwin van Rijkom which I have been meeting already at Spark Europe. He is the author of Screenweaver so already knew very well about the technology needed for previously called haxeDesktop project. He was very enthusiast from the beginning and started writing most of the code by himself, with crossplatformability in mind. I was very busy at this moment so not really helpful. During theses important first weeks, Edwin really did great work.

Once most was done, it was time to start interacting with the System/Neko Layer. Edwin started working on it but it was more my specialty so I took over the task. Two big changes occurred at this time. The first was to change from an EXE-centric model were SWHX itself was loading the Neko code to an SWHX DLL that was used just like any other Neko library. This is important since it means that you can use SWHX like any other Neko library from any Neko supported language. Also, it gave back the control of the whole API to the Haxe/Neko layer which was better. The other change was to turn all the C++ code into plain C code, which was better to interact with the Neko C FFI which is more C-oriented.

Once the new architecture ready, I started integrating the code Edwin wrote which was fairly simple since most of the testing was already done. One of the nice ideas was to let handle the getURL calls by the Neko Layer. This way, while there is a default behavior which is to either load a local file or fetch an URL content, the SWHX user can override this behavior and handle its own file loading, access permissions and hard drive caching mechanisms.

One last issue was the Flash Player integration. SWHX requires the Firefox Flash Plugin to be available. That's problematic since the Player is not redistributable. There is a form to ask for permission but in practice only a few companies have been granted this usage and Adobe (formerly Macromedia) has always been pretty evasive regarding this issue. Our way to deal with that is pretty simple : if the DLL is not found, download the Player archive from Adobe website, unzip it to extract the DLL and save it into the current directory. This behavior is optional and customizable by the SWHX user but for the Application end-user it's completely transparent and will only notice a small lag when starting the Application for the first time.

SHWX is currently working on Windows and Edwin will finalize the Mac port as soon as he come back from his merited holidays. As for Linux, there are two important things to deal with :

  • port the "system.c" which is just an interface for creating a window and handling some OS-specific stuff. It's only a few Ko of sources so it should be quick. Once done it means you can display the player.
  • the biggest problem is that since there is no FP8 for Linux it means no ExternalInterface and then no synchronous communications between the System and Flash layer. A first solution can be to have at least async communications by using FSCommand, then later maybe find a "hack" to enable synchronized communications on FP7 (we have some ideas but nothing done).

In only one-month-and-half since the project started, we could provide a great tool for all Flash and Haxe users. I would like especially to thanks Edwin since nothing would have been possible without him.

0 comment
Name : Email : Website : Message :