Age | Commit message (Collapse) | Author |
|
anywhere anyone wanted to Get[Font|Color] give it the Label
ones instead.
why this is exposed through uno is bewildering, stubbed those
out for the moment
Change-Id: I7a31d027287436be1c075c76a370047efd010bf3
|
|
Change-Id: I544d42994bd46171d5d507af450cd1ca5f9c912a
|
|
ditch the CAIRO_VERSION_ENCODE(1, 10, 0) + sub optional
damage rect and just use our always-available basegfx
foo here.
Change-Id: I680453180f4725ac37cabf38d71b935c99edf6c7
Reviewed-on: https://gerrit.libreoffice.org/21971
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I068d404431d3565f6ad5741edbd3693225824a4d
|
|
Change-Id: I2d60a6d70ca9d63f49b12b5d4c3855cc4ef53478
|
|
Change-Id: I180ed41a52e8f83fba86fb07e79ae2a7a3f095fc
|
|
Change-Id: I05ce4ddb4c933eb1100e3a3410cea27520072933
|
|
Change-Id: Ida1447bad7f81ebfcc0da1e8278a74c11a139afe
|
|
Change-Id: Ic3f7fddcea36c18ffe43c4c633d415f596a58cbc
Reviewed-on: https://gerrit.libreoffice.org/19094
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I6eb213d6dcf387936967271fba9e2de3879ef479
|
|
Change-Id: I62076450ab77472bfd09b3fb9824f54b6ea1e0f7
|
|
|
|
|
|
|
|
Change-Id: Ia41276033c1f656217bc3ae929faab001db36ca4
|
|
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
|
|
Change-Id: I155e45f58974a2b946c4a7703b350bcbfbad342e
|
|
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
|
|
Change-Id: Ie6a0c86b18a7a01c8b020c37dcbcadc529deb80b
|
|
Change-Id: I25b1ce4396a8e125b23e088310b970ef746cbaf0
|
|
Change-Id: I57d4e43460e40d3aff54873280eddbb18c12446b
|
|
Change-Id: I290ccba1487e59ea6f86bfb0382671ca4ed50831
|
|
Change-Id: I81ce8fd7022bf283db668705efdfb0666f87bde9
|
|
Change-Id: If83b12578ce1e5dcae688589e92a54b96040abdd
|
|
change code like
aStr = OUString("xxxx");
to
aStr = "xxxx";
Change-Id: Ib981a5cc735677ec5dba76ef9279a107d22e99d4
|
|
Change-Id: I0d842cc951cb5a3e7e990f835f541ccf1bd89df6
|
|
Change-Id: I4067c5039c7b5c74a1c144721dd7260de54dd2bf
|
|
there are a lot more of them:
git grep 'createFromAscii[^)]*"'
Change-Id: Ibc2e9cae208d8b9c91667bb3b177c6bd6d3a9424
|
|
|
|
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
|
|
Change-Id: I9321dcf9d863cb59eee9b2a012d887a17cb1b454
|
|
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
|
|
Change-Id: If7245ceea45a517084fdb5df09818e4e6e8c8be5
|
|
No need to take a parameter for which NULL is always passed, and related
simplifications.
Change-Id: I89bab2904fdae3520987d0f67e55b2649bf225d3
|
|
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
|
|
Change-Id: I74f1d7feb935be65629bdbd7464f9882229948e5
|
|
Don't know what this affects, though. Things seem to have worked as expected
even with the hardcoded bogus value?
Change-Id: I945bdcd53260fc5f43cf0031dfd96637168475f0
|
|
Change-Id: I815cc4a703b7ca6d2894807396a06a3394b40676
|
|
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
|
|
Change-Id: I1d825c39cde67c204110b4a787b3ffb290331fe5
|
|
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
|
|
Change-Id: I57702d2d848181f2df4af3fc0d1ce8cbed1455f9
|
|
On the internal ("Sal") VCL level they will correspond to wheel mouse events,
I guess.
Change-Id: Ia422f892d73afe501f529020c2aed9ff8fca99f9
|
|
Change-Id: I0c50dea9d86d3ec15ec327883867a384cbf2a6e8
|
|
Change-Id: Ibc9aad490c4616d339e95352a0b8a7f7bed93070
|
|
Change-Id: I460614dba8f162a8bedcf0bf847614fae9b05910
|
|
Change-Id: Ib4434400b110f8056b3291c0d48fe6548a7a9e8e
|
|
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
|
|
Change-Id: Idded90eaa68481dbb9b4045ff62a54e13c7baa31
|