Has all been obsoleted by LibreOfficeKit.
Only some MOBILE_* constant #defines are now left in touch.h, but probably
those are used only by dead code.
Change-Id: I646945c4408b4e6cd5510da535cfc12088dd391c
As we call AttachCurrentThread() in the constructor, it seems logical to call
DetachCurrentThread() in the destructor. Some warning messages in the logcat
indicated that DetachCurrentThread() hadn't been called for a thread that
died.
Actually I would prefer to call both AttachCurrentThread() and
DetachCurrentThread() in the actual thread function, instead of somewhat
haphazardly and imlicitly in the AndroidSalInstance constructor and
destructor. Do we know for sure that the lifetime of the AndroidSalInstance
singleton (is is a singleton, right?) is 1:1 coupled to that of the LO "main
thread"?
Change-Id: Ifcc0e0b9af88b19389c416c5646499d44ad0e941
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
