Added a message callback interface to Document where the provided
implementation processes the messages from LOK (for now
only the regions that were invalidated)
Change-Id: Ic7fcb0250f87f6c4c28925bf809c4cf3f353d2bb
This adds support to retrieve callbacks from LibreOffice (like
for example that a part of document has been invalidated) to
LibreOfficeKit JNI and Java wrappers.
Change-Id: Ib70187194d002c72b64d58032aab216adc591565
The only use of it is commented out. ThumbnailGenerator used the UNO-based
XToolkitExperimental stuff that I want to get rid of. If/when we want
thumbnails, we should use the existing thumbnails from document formats that
have them, or generate them using LOKit.
Also remove stuff from the Bootstrap class that was only used by
ThumbnailGenerator.
Conflicts:
android/experimental/LOAndroid3/src/java/org/libreoffice/ui/LibreOfficeUIActivity.java
Reviewed on:
https://gerrit.libreoffice.org/13503
Change-Id: Ia3a1a7f372a814359c5b496cdb17c35246e34817
Using direct ByteBuffer is much nicer option to store or send
pointers between C(++) code and Java via JNI as it handles endiness
and pointer size for us. Using "long" type can have unexpected
results in 32-bit architectures (mostly Android). This was causing
grief especially when Android introduced support for 64-bit
architectures starting with SDK 19.
Change-Id: Ie92d0f913b668e1724e846d70d1820445d9cb086
DirectBufferAllocator is responsible to allocate buffer. We used
Fennec JNI based allocation (and freeing) because of overallocation
bug in some Android versions. With this the VM based allocator
implementation is added and used by default because of bugs that
happen in newer Android versions (specifically when ART is used
as the Android VM).
Change-Id: I07eb364fd1647b3a09d1568d4fef82398a02dfeb
As part of LOK initialisation we now start soffice_main, this
requires TMPDIR access, and will fail if we haven't set TMPDIR
(as by default it attemps to access /tmp which is not allowed on
Android).
Change-Id: I63bd7bce9b52c898c60fda6eea33ee919349a109
+ prevent lokandroid JNI functions to be removed from the library
+ basic use of lok Office / Document in LibreOfficeMainActivity
Change-Id: I7bfe53738cf821b2270ab3e024cc506a7cff42f0
We need to have the files extracted before we attempt to initialize
LibreOfficeKit (call libreofficekit_hook), otherwise the .rdb's are not there.
Change-Id: Ib49db7e945a709d18a063eb488a27df18fef542b
Now the LibreOfficeKit is used to actually attempt to bootstrap LibreOffice;
at the moment fails to do that.
Change-Id: I91220dbff783213bf7702e7213a5646859db4581
Move the native methods out to a separate AppSupport class so that they aren't
in our "experimenal" Desktop app's namespace. Don't hardcode the name of that
class in the native code, but have the app register the class to which the
damage callbacks should be done.
Possibly the AppSupport and Bootstrap classes should be combined. Later.
Also, the "android" part of the package name is superfluous; it is
Android-specific code, no information gained by having an "android" part in
the package name.
Change-Id: Iddf55c8034ead7693887ace8438deb002c5eea9f
Partially revert 52a8744afee2cd589813f0377d93f821fce7aedd, i.e. once again
start to remove stuff related only to using NativeActivity... (Because it is
confusing and misleading to keep it around.) Let's do it in small pieces this
time.
Change-Id: Ifdc52eb0ae32c7c510418611cbf01a857a8bc697
We haven't been able to build NativeActivity-based apps (like the
android/qa/sc and anroid/qa/desktop thingies) since we switched to
DISABLE_DYNLOADING and a single DSO liblo-native-code.so anyway.
No lo_main() any more. <sal/main.h> should not be included ever when
compiling for Android of iOS now.
Lots of stuff binned from vcl's androidinst.cxx, in the (vain?) hope
that it will reduce the amount of never invoked GUI code that gets
linked in.
Change-Id: I25f584864c40110774c728a23151e089620442d9
As we don't use any dlopen() etc wrappers now with just one single
DSO, we have no use for the library search path either.
Change-Id: Ifaf11c4785a90fe5c7dafb3310bc7933ea31238c
We gzip them separately in the Makefile and the gzipped result will be
stored without (further) compression in the .apk.
Use this to store the ttf font files. Shaves off a bit .apk size.
This might seem a bit odd way to do it, why not store these files in
the normal Zip compressed fashion in the .apk? It seems hard to tell
Ant (based on path, not extension) what files to compress and what
not, so we have to keep telling it to not (further) compress any files
at all.
Change-Id: I0d40d8811e6c9df6b28c285845b1db225507f5d4
IN this branch these changes are not conditional. Unclear yet whether
this is what we finally will want to use or not. Maybe should make
these changes conditional and do this stuff in master instead?
Change-Id: I379d570a0e00648d295c675fd90eba6594ba3182
Modify DocumentLoader correspondingly. Take Android bug 32588 into
account.
Ideal would be to extend the XDevice stuff, or something, so that one
could hand it a pre-allocated RGBA buffer into which the
drawing/rendering would go. Then one could get rid of the silly
convert-to-BMP phase, which prefixes the bitmap data with BMP and DIB
headers (and thus, I guess, has to copy and allocate another
copy). Will see.
Change-Id: I4597cd933db8faa8105dc8f19638d712d5d2238a
