Building Rig

Dependencies

1. SDL 2.0 (Simple DirectMedia Layer):

   Rig uses SDL 2.0 as a portable way to create an OpenGL context and provide input support.

   You should build against the rig branch hosted under the rig-project here

2. LLVM, Clang, MCLinker:

   Rig uses Clang and MCLinker to be able to compile user entered code that can run in response to property changes for example.

   You should build against the rig branch of these hosted under the rig-project: https://github.com/rig-project/

   LLVM and Clang can be built as follows:

    git clone https://github.com/rig-project/llvm.git
    cd llvm/tools
    git clone https://github.com/rig-project/clang.git
    cd ../
    mkdir build
    cd build
    ../configure --prefix=~/rig-build --enable-debug-runtime --enable-debug-symbols --enable-shared --enable-keep-symbols --enable-targets=x86,x86_64,arm
    make install
   

   MCLinker can then be built as follows:

    git clone https://github.com/rig-project/mclinker.git
    cd mclinker
    ./configure --prefix=~/rig-build --with-llvm-config=~/rig-build/bin/llvm-config
    make install
   

3. Freetype, Harfbuzz, ICU + Fontconfig:

   Rig uses these libraries for rasterizing glyphs, shaping glyphs, dealing with Unicode (including implementing the BiDi algorithm) and for font selection.

   You should build against the rig branch of ICU hosted here. For Freetype, Harfbuzz and Fontconfig then a standard up to date version provided by most Linux distributions should be ok.

   ICU can be built as follows:

    git clone https://github.com/rig-project/icu.git
    cd icu
    ./configure --prefix=~/rig-build -DU_USING_ICU_NAMESPACE=0 -DU_CHARSET_IS_UTF8=1  -DUNISTR_FROM_CHAR_EXPLICIT=explicit -DUNISTR_FROM_STRING_EXPLICIT=explicit -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS
   

4. libuv: libuv provides a minimal, portable mainloop implementation

5. protobuf-c: Rig uses the Protocol Buffer format for serializing UI descriptions to disk and also when communicating over the network between the editor and a slave devices.

   You should build against the rig branch hosted here.

6. Pango:

   The Rig editor currently relies on Pango for complex text layouting, though the plan is to migrate to Rig's own text layoutng and rendering code later.

   A standard up to date version provided by most Linux distributions should work fine.

Rig is a standard autotooled project, so once you have fetched the above dependencies then building Rig is just a matter of running:

    ./configure
    make
    make install

Note: Rig can't be run uninstalled currently since the editor won't find its assets. Once you have installed the assets though then it's possible to run incremental rebuilds of Rig in place without re-installing.

For deploying completed applications Rig's editing capabilities can optionally be disabled at build time leaving only the minimal runtime. This is done by passing the --disable-editor argument to the ./configure script.

Running

Building rig will result in three binaries, rig, rig-device and rig-slave:

1. Editor Mode

   This mode is for interactively designing a new user interface. The editor is use by running the 'rig' binary giving it a path to a UI.rig file like:

    rig /path/to/my/ui.rig
   

   If the file doesn't exist then it will be created when you save by pressing Ctrl-S so long as the parent directory already exists.

   Note: When Rig is run in editor mode it will automatically search for image assets under the parent directory of your ui file. (So under /path/to/my for the above example) Because of this, it would not be recommended to create a new ui.rig at the top of your home directory.

2. Device Mode

   Once you have a UI that you want to run as an application Rig can instead be run in a chromeless device mode like this:

    rig-device /path/to/my/ui.rig
   

3. Slave Mode

   The usage model we are aiming for with Rig is that UI design is connected to UI testing on real hardware. The aim is to directly connect the prototyping and visual design stages to the technology that will be used to run the UI (both hardware and software). This way we think Rig will make the whole development process more efficient.

   Rig can be run in a slave mode that is similar to device-mode but also has network connectivity to a Rig editor. By running Rig in slave mode on a device the editor will be able to discover the device via the Zeroconf protocol and connect to it. While connected then UI changes made in the editor will be immediately synchronized with the slave device. This way UI changes, such as timing changes for an animation can immediately be tested for their performance, quality and responsiveness on real hardware. Experience working directly with the hardware will be able to influence the design at the earliest stages when the designs are easy to change.

   Running in slave mode is just done like this:

    rig-slave
   

   No UI.rig path need be given since the editor will send the UI to slave once connected.