summaryrefslogtreecommitdiffstats
path: root/vcl/android
Commit message (Collapse)AuthorAgeFilesLines
* Kill dead <touch/touch.h> APITor Lillqvist2015-03-241-17/+0
| | | | | | | | | 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
* fdo#84938: convert VCL_INPUT_ #defines to 'enum class'Noel Grandin2015-01-071-2/+2
| | | | Change-Id: I155e45f58974a2b946c4a7703b350bcbfbad342e
* Call DetachCurrentThread() in the AndroidSalInstance destructorTor Lillqvist2014-12-041-0/+2
| | | | | | | | | | | | | | | | 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
* These constants are now in the MouseEventModifiers class enumTor Lillqvist2014-11-081-3/+3
| | | | Change-Id: Ie6a0c86b18a7a01c8b020c37dcbcadc529deb80b
* Use vcl::FontTor Lillqvist2014-09-181-1/+1
| | | | Change-Id: I25b1ce4396a8e125b23e088310b970ef746cbaf0
* ErrorBox->MessageDialogCaolán McNamara2014-08-181-3/+3
| | | | Change-Id: I57d4e43460e40d3aff54873280eddbb18c12446b
* cppcheck: Prefer prefix ++/-- operatorsJulien Nabet2014-05-241-1/+1
| | | | Change-Id: I290ccba1487e59ea6f86bfb0382671ca4ed50831
* Kill superfluous vertical whitespaceTor Lillqvist2014-04-021-1/+0
| | | | Change-Id: I81ce8fd7022bf283db668705efdfb0666f87bde9
* vcl: try to make android tinderbox happy tooMichael Stahl2014-02-201-0/+1
| | | | Change-Id: If83b12578ce1e5dcae688589e92a54b96040abdd
* remove unnecessary use of OUString constructor when assigningNoel Grandin2013-11-191-1/+1
| | | | | | | | | change code like aStr = OUString("xxxx"); to aStr = "xxxx"; Change-Id: Ib981a5cc735677ec5dba76ef9279a107d22e99d4
* Hacking on iOS keyboard handlingTor Lillqvist2013-10-131-2/+8
| | | | Change-Id: I0d842cc951cb5a3e7e990f835f541ccf1bd89df6
* Turn basebmp::Format into a proper enumStephan Bergmann2013-07-121-1/+1
| | | | Change-Id: I4067c5039c7b5c74a1c144721dd7260de54dd2bf
* remove some createFromAscii usageThomas Arnhold2013-06-291-1/+1
| | | | | | | | there are a lot more of them: git grep 'createFromAscii[^)]*"' Change-Id: Ibc2e9cae208d8b9c91667bb3b177c6bd6d3a9424
* Move to MPLv2 license headers, with ESC decision and author's permission.Michael Meeks2013-04-221-24/+4
|
* Small refactoring of the Android "desktop app" code, no functional changeTor Lillqvist2013-04-191-43/+46
| | | | | | | | | | | | | | | 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
* Start implementing on-demand keyboard display for non-DESKTOPTor Lillqvist2013-04-121-3/+17
| | | | Change-Id: I9321dcf9d863cb59eee9b2a012d887a17cb1b454
* mass removal of rtl:: prefixes for O(U)String*Luboš Luňák2013-04-071-18/+18
| | | | | | | | 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
* Bin redundant loggingTor Lillqvist2013-03-301-3/+0
| | | | Change-Id: If7245ceea45a517084fdb5df09818e4e6e8c8be5
* AndroidSalInstance::RedrawWindows() is called from only one placeTor Lillqvist2013-03-171-22/+4
| | | | | | | No need to take a parameter for which NULL is always passed, and related simplifications. Change-Id: I89bab2904fdae3520987d0f67e55b2649bf225d3
* AndroidSalInstance::Wakeup() is unusedTor Lillqvist2013-03-081-6/+0
| | | | | | | | | | 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 crash the other experimental appsTor Lillqvist2013-03-081-11/+21
| | | | | | | | | | | 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
* Start hacking on scrollingTor Lillqvist2013-03-071-0/+17
| | | | Change-Id: I74f1d7feb935be65629bdbd7464f9882229948e5
* Use view size for "work area" sizeTor Lillqvist2013-03-071-1/+1
| | | | | | | Don't know what this affects, though. Things seem to have worked as expected even with the hardcoded bogus value? Change-Id: I945bdcd53260fc5f43cf0031dfd96637168475f0
* Now get rid of the #if 0 blocksTor Lillqvist2013-03-071-444/+0
| | | | Change-Id: I815cc4a703b7ca6d2894807396a06a3394b40676
* Handle damage tracking and redrawing properly in the "desktop" Android appTor Lillqvist2013-03-071-9/+21
| | | | | | | | | | | | | | | | | | | 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
* Drop unused timestamp parametersTor Lillqvist2013-03-061-6/+4
| | | | Change-Id: I1d825c39cde67c204110b4a787b3ffb290331fe5
* Add SvpSalInstance::PostedEventsInQueue()Tor Lillqvist2013-03-061-3/+4
| | | | | | | | 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
* Add a SAL_INFOTor Lillqvist2013-03-051-0/+1
| | | | Change-Id: I57702d2d848181f2df4af3fc0d1ce8cbed1455f9
* Start hacking on zoom and scroll events at the VCL "public" levelTor Lillqvist2013-03-021-29/+29
| | | | | | | On the internal ("Sal") VCL level they will correspond to wheel mouse events, I guess. Change-Id: Ia422f892d73afe501f529020c2aed9ff8fca99f9
* RTL_CONSTASCII_USTRINGPARAM removalTor Lillqvist2013-03-021-5/+4
| | | | Change-Id: I0c50dea9d86d3ec15ec327883867a384cbf2a6e8
* Start hacking on zoomingTor Lillqvist2013-03-021-0/+16
| | | | Change-Id: Ibc9aad490c4616d339e95352a0b8a7f7bed93070
* Bin two lines of logging that are too repetitive to be usefulTor Lillqvist2013-03-011-22/+2
| | | | Change-Id: I460614dba8f162a8bedcf0bf847614fae9b05910
* The RGBA bytes are already in the order we wantTor Lillqvist2013-03-011-2/+2
| | | | Change-Id: Ib4434400b110f8056b3291c0d48fe6548a7a9e8e
* Drop unuse maRedrawRegionTor Lillqvist2013-02-281-37/+2
| | | | | | | | | | | | 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
* Try uncommenting these now, I don't think the FIXME holds any moreTor Lillqvist2013-02-281-3/+2
| | | | Change-Id: Idded90eaa68481dbb9b4045ff62a54e13c7baa31
* Try to use another kind of eventsTor Lillqvist2013-02-281-22/+14
| | | | | | | | 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
* Bin one more too repetitive log lineTor Lillqvist2013-02-281-1/+0
| | | | Change-Id: I0ab4ecc4791cd319c8c25583e5207dcfc66b0fac
* WaE: 'eventKind' may be used uninitialized in this functionTor Lillqvist2013-02-281-0/+3
| | | | Change-Id: I55b2a2bd4cffface671727f88a3da9b132d7637a
* The "pre-cleaning" is fairly pointless now when we fill the whole screenTor Lillqvist2013-02-281-1/+1
| | | | Change-Id: I85a2ee8af9615222c33b36e3d7d08e5821a66a43
* Bin some repetitive verbose loggingTor Lillqvist2013-02-281-5/+3
| | | | Change-Id: I5c2ee005094ec3fdf1ebc766b0760a1f73b2682f
* Handle touch eventsTor Lillqvist2013-02-281-2/+41
| | | | Change-Id: I9c9d200731df9ba48ee61f7c97692ed9b9f06648
* Send text input to the LO codeTor Lillqvist2013-02-271-1/+28
| | | | Change-Id: I28070fb1a8b85c9737d2a78a8a713243ce47dde9
* Remove a too verbose and frequent log writeTor Lillqvist2013-02-271-48/+40
| | | | Change-Id: Ie6ecf61d9acabb87a24f95f878b874a04532131d
* The source buffer (virtual device) has 4 bytes per pixel, tooTor Lillqvist2013-02-251-5/+4
| | | | | | | Now the desktop-style Writer window looks fine on my device. (The app still crashes quickly, though.) Change-Id: I2542fba653cfef651f207388f1fd98d186485d3b
* Temporary (one hopes) hack to get the actual view size down to SvpSalFrameTor Lillqvist2013-02-251-0/+16
| | | | Change-Id: I0c2a2301de1b0de71fc6724ff2af73fbf6b406ef
* Use __android_log_print() instead of fprintf(stderr)Tor Lillqvist2013-02-251-81/+85
| | | | | | | | | | | | | | | | | | | | | 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
* No NativeActivity, so native_app_glue and struct android_app are meaninglessTor Lillqvist2013-02-231-28/+36
| | | | | | | Leave the NativeActivity-related code in androidinst.cxx for reference for now. Change-Id: I760c02ea361361be2d2b69c4cad1e38311f51247
* Rename the package and .apk of the "desktop" test app to avoid confusionTor Lillqvist2013-02-221-3/+3
| | | | | | | | 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
* android: finally starting and rendering at least something again.Michael Meeks2013-02-211-14/+94
| | | | | | | 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
* Revert "Clean up remains of NativeActivity-based Android app support"Michael Meeks2013-02-211-17/+685
| | | | | | | | This reverts commit cecc926070ee3d2ad6296fc5e0cfcde8642bb140. Conflicts: sal/android/lo-bootstrap.c sal/inc/osl/detail/android-bootstrap.h