Development/Impress/Remote

This page describes development of the Impress Remote.


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

Builds
See Impress Remote

Components
The remote protocol is documented in 'sd/README_REMOTE' ( https://cgit.freedesktop.org/libreoffice/core/tree/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:
 * https://git.libreoffice.org/impress_remote/

Preamble
Ensure that you run the setup-git-hook 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 10.0.2.2 to connect to a LibreOffice instance running on the same physical host.

Dependencies

 * 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
See the readme for up-to-date build instructions.

Testing the build
You will be able to find the ready .apk in: android/sdremote/bin/ImpressRemote-debug.apk

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

Localization

 * Use android2po tool to convert strings.xml to template.pot.
 * Upload template.pot to Weblate, Impress Remote project.
 * Update .po files (Update from templates).
 * Let translators work on the files.
 * Download files from Weblate, put them to  folder, and run.

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: ios/iosremote/

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

Localization
Use  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

Protocol
The protocol is documented in sd/README_REMOTE ( https://cgit.freedesktop.org/libreoffice/core/tree/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.

History
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).