From The Document Foundation Wiki
Jump to: navigation, search

This page describes development of the Impress Remote.

For a more general page about the app, see Impress Remote


See Impress Remote#Builds


The remote protocol is documented in 'sd/README_REMOTE' ( ).

LibreOffice Server

This is an integral part of LibreOffice itself, the sources are in 'sd/source/ui/remotecontrol'. To hack on this you will need a full LibreOffice build.

Android App

This is a standalone app, the sources for which are in 'android/sdremote'. See below for details on how to build -- hacking on this doesn't require a full build of LibreOffice.

iOS App

This is a standalone app, the sources for which are in 'ios/iosremote'.

Source Code

Source code for the Impress Remote lives on gerrit in the impress_remote repository:

How to Build the Android App


Ensure that you run the


script located in the root of the repository, before starting to work on the remote.

If you are testing the app in the emulator you will need to use the IP address to connect to a LibreOffice instance running on the same physical host.


  • Android SDK.
    • Android 14 Packages (install using the Android SDK Manager, found in tools/android within the sdk).
    • Android v4 support library.

Using command line

This is outdated -- we now use gradle:

Make sure you have the ANDROID_SDK_HOME and ANT environment variables set properly.

cd android/sdremote

Testing command-line or gbuild build

You willbe able to find the ready .apk in:


To test this using an emulator/phone you can do:

cd /path/to/sdk
./tools/android // Only if using emulator. Select "Tools->Manage AVDs...", create a new image if necessary, and start the image.
(If using a new emulator/phone you will need to ensure that it is set up to allow USB debugging, and that the USB permissions are set up correctly)
./platform-tools/adb install /path/to/apk


  • Use android2po tool to convert strings.xml to template.pot.
  • Upload template.pot to Pootle, Impress Remote (Android) project.
  • Update .po files (Update from templates).
  • Let translators to work on the files.
  • Download files from Pootle, put them to locale/ folder, and run a2po import.

How to Build the iOS App

You will need to have XCode installed (also needed to build LibreOffice in general) -- to work on the remote point XCode at the folloing location:


If you are using a newer version of XCode it might try to update the project files -- you should avoid committing such changes unintentionally.

If you are only working on the remote and haven't done any other LO work please make sure you run the following command before committing to ensure that the commit hooks are installed (they are automatically installed as part of a full build, but that is ommitted if you are only working on the app):

./g -z


Use prop2po from Translate Toolkit to create pot files from strings files, and to convert localized po files back to localized strings files.

For example to convert Localizable.strings to Localizable.strings.pot:

prop2po -P ios/iosremote/iosremote/en.lproj/Localizable.strings Localizable.strings.pot

Back-conversion of French translation (Localizable.strings.po) to strings format:

po2prop -t ios/iosremote/iosremote/en.lproj/Localizable.strings Localizable.strings.po ios/iosremote/iosremote/fr.lproj/Localizable.strings


The protocol is documented in sd/README_REMOTE ( ), however the definitive resource is the source code of the server located in sd/source/ui/remotecontrol.

This is a simple text-based protocol that should easily be parseable in most environment and languages. The protocol is easily extendable since any unrecognised but complete commands will simply be ignored by the client and/or server without causing errors.


During the very early stages of development (beginning of summer 2012) a JSON based protocol was used, however this was quickly replaced in favour of a text-based protocol to reduce dependencies and simplify use on all platforms (mainly the difficulty in easily accessing a json parser on the C++ side of things across all platforms without introducing extra dependencies) -- given the small number of commands this is seen as being perfectly sufficient. Binary and JSON based protocols were suggested during the GSOC 2013 term, however ultimately the current protocol was kept to guarantee backwards compatibility and to simplify development (i.e. no need for extra dependencies on any platform and/or complicated parsing code). All released clients speak this text based protocol (as of October 2013).