office-gobmx/touch
Stephan Bergmann ab149c7e3f Get rid of UnoApiMerge_uretypes, which is just a duplicate of UnoApi_udkapi
What is a little confusing is that the udkapi.rdb ends up as types.rdb in the
installation set (in the URE's sub-tree).  So all places that reference it
during the build do so as "udkapi" while all places that reference it in an
installation set do so as "types."

Change-Id: I35d0695966b3bd703f5494b636b9782efc0d3fcb
2013-04-24 10:51:31 +02:00
..
idl/org/libreoffice/touch
source
CustomTarget_touch_javamaker.mk Get rid of UnoApiMerge_uretypes, which is just a duplicate of UnoApi_udkapi 2013-04-24 10:51:31 +02:00
InternalUnoApi_touch.mk
Library_libotouch.mk
Makefile
Module_touch.mk execute move of global headers 2013-04-23 22:20:31 +02:00
README

Library that provides API used by LO-based apps on touch devices

This is all very much a work in progress and the design can change
radically at any moment. And actually at the moment it is unclear
whether this will be used or not.

The name "touch" for this module and the library name "libotouch" are
not fixed and might change if somebody comes up with niftier names.

This module will contain an UNO API to be called either from Java (for
Android), or directly (iOS). (Or, on iOS, possibly through some thin
Objective-C layer to hide the UNO.)

The API will provide a mechanism to render "tiles" of a document at some
requested zoom level. Initially for viewer style apps, but the work should
ideally be open-ended to potentially be a base for editing apps, too.

For starters, concentrating on text ("Writer") documents as they are
easiest. With spreadsheets come the added complexity of the cell grid being
potentially unbounded and no clear "page" area. With presentations come the
animation complications, and possibly LO-based viewer apps for presentations
will be done in a totally different fashion.