Up to this point in time of writing, everything that we've discussed is available. However, there is a new world coming in the LiveCode 8.0 development. The following text is a look at the future as presented at the RunRev14 conference in September 2014 and as presented in an early 2015 newsletter status report by Benjamin Beaumont of LiveCode. We have been hearing about an Open Language and Widgets. Some of the terminology and details may change from what we present here. Indeed, Open Language already has seen the terms of LiveCodish, Modular LiveCode, and now LiveCode Builder.
While all the previous add-ons were extensions, the term is taking on an expanded meaning. An extension is a black box that extends the engine in some way, exporting handlers that perform specific functions. They are insulated from the rest of the engine and each other.
The new Extensions can be libraries or widgets. Libraries are the replacement for externals, add commands, and functions that are like the built-in ones and are not in the message path. Parameters can be typed, eliminating the need for repetitive type checking of the code. They also support seamless usage of foreign code. Libraries are written in exactly the same way as a widget except that any "public" handlers in the library are made available as syntax in the LiveCode Script.
A Widget in LiveCode is a script that has direct access to the 2D drawing library and a canvas to draw on. Widgets are like existing built-in controls that you select from the tools palette. In particular, widgets have complete control over how they respond and which messages the LiveCode script sees.
Widgets are implemented as a collection of event handlers, such as mouseEnter, mouseLeave, mouseMove, mouseDown, mouseUp, mouseRelease, keyPress, save, load, and finally paint. The paint event is called to render a widget using 2D canvas syntax. All operations use floating point coordinates, so we will have subpixel positioning. Widgets will be able to have a tree of child widgets internally, so that complex widgets can be built out of simple widgets.
Extensions are built and distributed as single file archives that contain a compiled LiveCode Builder, the original LiveCode Builder source (nonoptional if an open source extension!), compiled foreign code (if needed), and file-based resources private to the extension.
Extensions will be versioned so that you can put out maintenance updates and feature updates. No action will need to be taken by the LiveCode user for maintenance updates, but the user will need to choose when to update LiveCode for feature updates.
Extensions can require that other extensions be installed and the IDE handles this seamlessly. If you load a stack requiring extensions that you don't have, the IDE will go and find them, but you might have to pay for some of them!
LiveCode Builder is a variant of the existing LiveCode language designed to be a 'systems-building' language. It is a minimal language and all its functionality is notionally provided by libraries. Foreign code bindings are built in and they are statically compiled as bytecode.
One of the design goals of LiveCode Builder was the ease of translation to web-based technologies (JavaScript and HTML5). As LiveCode 8 matures, the plan is to move parts of the existing engine functionality into libraries written in LiveCode Builder, allowing most of the engine to be shared between HTML5 and traditional platforms. This is a key milestone on the journey to get HTML5 support.
How does LiveCode Builder code compare it with the current scripting language? For all the basics such as repeat/if/switch/put, it's much the same if not identical. The primary difference is that you have to specify the type for variables and instantiate them. Here is an example:
variable tArray as array put the empty array into tArray put "ben" into tArray["name"] if tArray["name"] is "Ben" then answer "I found" && tArray["name"] end if
The other difference is that there is lots of new syntax to do things that previously weren't possible. For example, drawing a widget on screen accesses a canvas API. You also have to add some default setup to tell LiveCode what to do with the source file and what libraries to use. Here is a simple example of a pink circle widget:
widget com.livecode.extensions.beaumont.pinkCircle metadata title is "My Pink Circle" metadata author is "Benjamin Beaumont" metadata version is "1.0.0" use com.livecode.canvas public handler OnPaint() // Create a path with a radius of half the width of the canvas variable tCirclePath as Path put rounded rectangle path of my bounds with radius my height / 2 into tCirclePath // Set the paint to a solid pink color set the paint of this canvas to solid paint with color [1, 0, 1] // Fill the path fill tCirclePath on this canvas end handler end widget
RunRev updates the LiveCode Roadmap about once a year. You can find the most recent one at:
http://livecode.com/community/roadmap/
LiveCode version 8.0 will encompass what we discussed previously and is the basis for many more advancements. The Open Language will be used to complete network, socket, and database libraries with English-like syntax as part of the development and testing process of this feature. Widgets will be the basis for improvement in controls to play videos across all platforms and a new vector shape object. A new IDE will be developed based on the previous technologies.
In August 2014, RunRev completed a $400k fund raising effort to add HTML5 support to the LiveCode suite. The funding allowed the hiring of additional staff to support this effort. HTML5 web delivery will provide the ability to output your LiveCode applications into modern web browsers, allowing a faithful representation of your application within the browser environment. It uses HTML5 so it does not require a browser plugin. You will be able to author true web apps with LiveCode.
Several projects are queued for completion after this. A Physics Engine will incorporate Box2D into LiveCode along with an animation loop feature. A Windows 8 port to support Windows mobile devices will be based on the new platform API developed for the Macintosh Cocoa port.