If you’re using the latest release of LiveCode 8.0 then the answer to that question is incredibly simple: just open up your stack and drag a browser control (the icon that looks like a little picture of the Earth) from the toolbar onto your stack. Then you can resize it however you like and open up the property inspector to set the url you want the browser to display. Easy!

The recent development release of LiveCode 8.0 dp 8 is the first to include the new browser control, fulfilling a stretch goal of our successful Open Source LiveCode KickStarter campaign.

Previously, the only way to add a web browser to your stack was to use the revBrowser external. This required you to script everything using a sequence of revBrowser commands and functions to create the browser and set it up the way you wanted. This way of doing things is rather tricky to manage, requiring scripted handlers to show and hide the browser when switching cards, and making sure the browser is closed when closing the stack. One troublesome way of doing that was to loop through all open browsers and close them, which can lead to some puzzling bugs when browsers start disappearing from random stacks!

The browser control removes all of this complexity by behaving exactly as you would expect any other control that is part of your stack.

How to Add a Web Browser Control (or anything else!) to LiveCode

Version 8.0 adds a new control type to LiveCode – the widget. A widget is the basis for creating a whole slew of new types of control. Rather than the behaviour of the control being defined within the engine, each widget type uses LiveCode Builder script to implement handlers for the standard set of input events (mouse clicks, key presses, etc.) and also to draw itself within the widget’s OnPaint handler. In this way, many new custom control types can be created without having to dig into the internals of the LiveCode engine.

So how did I write and code an entire web browser in a widget? Well, I didn’t! As is often the case in software development, the easiest course of action is to use something that someone else created, in this instance libcef, which is a library based on the core of Google’s Chrome browser. The tricky part is using that native code library from a widget.

Note: I did write some native code for this project – a cross-platform browser library (libbrowser) that provides a common abstract interface to libcef and the native browser views used on Android and iOS. The reason for this was to keep the code within the widget relatively simple, and to serve as an example of how to use a fully cross-platform library (as opposed to the desktop-platform-only libcef) from within a widget.

LiveCode Builder allows widgets to access code written in other languages and compiled as a native library. This is done by declaring foreign handlers, making sure the handler’s signature (the name of the handler, and the type of each parameter and return value) matches that of the native code function.

In order to keep the library interface separate from its usage in the widget, I created a browser LCB library which contains the definition of the foreign types and handlers needed by the widget, along with some utility handlers dealing with browser properties and conversion of values received through javascript handlers. This LCB browser library is then used in turn by the browser widget.

Now the browser widget itself doesn’t do any drawing itself, as the browser library creates a native drawing layer for each browser appropriate for the UI framework on each given platform (HWND on Windows, NSView on MacOSX, X11/GDK Window on Linux, etc.) so rather than find a way to render each view into the OnPaint canvas, the widget code assigns the browser view as a native layer of the widget, from which point on the engine becomes responsible for managing the visibility, size, position, and layering of the native layer, ensuring that native layers behave consistently with other LiveCode controls.

The aim of this project was not just to create a browser control, but to also put in place the facilities needed for other developers to create widgets by embedding native layers within LiveCode. This should make it much easier to introduce existing native controls into LiveCode in a way that results in controls that are simple and easy for app developers to add to their stacks without jumping through the hoops of using an external library.