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
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
The Wakeup() in the base class, SvpSalInstance, is not virtual. So this
Wakeup() does not override the Wakeup() in the base class, as the author maybe
thought. I don't see in git history that it would have ever been called
explicitly on any AndroidSalInstance objects either. Or am I missing
something?
Change-Id: I932398e7c0a37a3048c5d372996fe6ac6f209887
Don't try to find the class org.libreoffice.experimental.desktop.Desktop in
the AndroidSalInstance constructor. It won't exist anyway except in that
specific app. Look up the class in the damaged() method where it is needed.
And actually, of course we should not hardcode the name of the app class like
that, but the app should pass its class down to the native code.
Change-Id: Ic15d5cc2c8d53be558711ca7a145d5489e34d298
Don't know what this affects, though. Things seem to have worked as expected
even with the hardcoded bogus value?
Change-Id: I945bdcd53260fc5f43cf0031dfd96637168475f0
In the damaged() method do a callback up to Java code in Desktop that
invalidates the view. For now store the view in a static field, but need to do
that in a cleaner way eventually. There might in some circumstancest be
several instances of the Desktop activity present. Obviously should also run
just one LO thread.
Get rid of the temporary self-invalidattion in onDraw() silliness.
Start the LO thread that runs soffice_main() from Java, not from native
code. Apparently only threads created from Java have proper class loaders in
Android.
No need for an own DoReleaseYield() in AndroidSalInstance, the one in the
SvpSalInstance base class does what needs to be done.
Change-Id: I4cb85b352fca1f1375f726620ec8c93d2047f113
Used by AndroidSalInstance::AnyInput(). Unfortunately there is no way to check
for a specific type of input being queued as the AnyInput() API would
want. That information is too hidden, sigh. Should fix that.
Change-Id: I2d971a7da531bb00a80fd39311fb70ab29359b08
I saw crashes or getting stuck in a loop in the Region code for some unknown
reason. Below in the backtrace was the call to Region::Union() in
AndroidSalInstance::damaged(). As the maRedrawRegion wasn't actually used for
anything, let's bin it then for now... No crashes now, knock on wood.
I still don't know whether the switch from SalFooEvents and CallCallback() to
FooEvents and PostFooEvent() helped anything or not.
Change-Id: Iba867daa37a206953cdb765905fa5eb3fca4d08e
I see randomish crashes that likely are caused by parallelism problems. Try to
see if using Application::PostKeyEventg() and PostMouseEvent() instead of
SalFrame::CallCallback() helps.
Change-Id: Ia97259a378fe40ff0dab3fbb538599e9d2e69c1f
Now the desktop-style Writer window looks fine on my device. (The app still
crashes quickly, though.)
Change-Id: I2542fba653cfef651f207388f1fd98d186485d3b
Printing to stderr is not at all any faster or more direct in an Android app
than just using the Android standard logging API.
Note that in a normal Android app, stdout and stderr are not connected
anywhere. (Just like in "GUI" subsystem (as opposed to "console") Windows
programs, heh.) It is our own code in sal/android/lo-bootstrap.c that
redirects stdout and stderr to pipes which we set up and which are read in a
separate thread that we start. The lines read are then, surprise, passed on to
__android_log_print(). Thus writes to stdout or stderr in "normal" LibreOffice
code aren't lost.
But in code that is by definition Android-specific it makes little sense to
use stdout and stderr.
(Much of the affected logging in this change is in NativeActivity-related #if
0'ed code, sure, so won't actually be reached.)
Change-Id: I409114f36f3e535bb144b4bde0d378110b3336a1
It used the same package name as DocumentLoader and the same .apk name as the
eary sc cppunit test app. Probably having two unrelated apps with the same
package name causes some confusion somewhere.
Change-Id: I11414b9cd59694eb97d39bfaeac4ed1066ae3aab
Only renders on very-first-start after install (oddly).
We initialize vcl in it's own thread to avoid problems.
Thanks to tml for fixing a linking issue.
Change-Id: I960d11c6098681356fea0634970545aa9af9bacb
...where all but the variants for Android and --enable-headless already did so
(and curiously the DestroySalInstance variants for Android and --enable-headless
already contained code to release the solar mutex). See the thread at
<http://lists.freedesktop.org/archives/libreoffice/2012-December/042535.html>
"--headless broken with --enable-headless" for further details.
Change-Id: I01be2e237e203a151ea8b1f3adfbcb3e63247cd7
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
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
