summaryrefslogtreecommitdiff
path: root/android/experimental
AgeCommit message (Collapse)Author
2013-04-02Typo: string.xml->strings.xmlZolnai Tamás
To make available for localization Change-Id: I5469549422c7a2d2618ed9e836895f6698328b17
2013-03-27Use proper version numbersTor Lillqvist
Change-Id: Ib0284c3fe63636e42b2e72ab76b02a8197c837e0
2013-03-07Try to make the scrolling and zooming actions snappierTor Lillqvist
Now it does work nicely during the gesture when all the action is on the Java side (translating and scaling the pre-rendered bitmap). Looks a bit sad, of course, that nothing scrolls in to replace the parts of page(s) scrolled out during the gesture, and correspondingly for zooming. To then get the stuff down in the murky depths of the LO code to do what I want still is beyond me. Change-Id: I9ce33ed482013d18a877d1798de3bce5ac608e5e
2013-03-07Start hacking on scrollingTor Lillqvist
Change-Id: I74f1d7feb935be65629bdbd7464f9882229948e5
2013-03-07Handle damage tracking and redrawing properly in the "desktop" Android appTor Lillqvist
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
2013-03-06Drop unused timestamp parametersTor Lillqvist
Change-Id: I1d825c39cde67c204110b4a787b3ffb290331fe5
2013-03-05Rework scaling once moreTor Lillqvist
Don't ask the LO code to zoom while scaling in progress. That is way too slow. Return to the idea of just scaling the already rendered bitmap containing the "top-level window" from LO's perspective, UI elements and all. (Obviously if we continue to work on thie demo app, the desktop style UI elements need to disappear from the sides of the LO "window", so that the only thing LO renders is the actual viewport of the document contents.) This time, instead of scaling the View, which for some reason causes horrible flickering glitches at least on my device, draw the bitmap scaled in onDraw. Much smoother for some reason. Of course when we then in onScaleEnd() ask LO to do the actual zoom, what eventually results (remember that the LO code runs asynchronously in a separate thread, and the zoom request only gets posted to that thread) is not at all the same as what just drawing the bitmap at scale produced. (Especially not as there is no way yet to have LO zoom centred on a specific pivot point.) Change-Id: Id80576c99a03f5f8bf0d8039c6c7406322581956
2013-03-04Field can be moved into the inner classTor Lillqvist
Change-Id: I053f7d4a17aec9c8b24b92a40de635c71492a3dc
2013-03-03Android "desktop" app: Simplify bootstrapping on the Java sideTor Lillqvist
No need to call defaultBootstrap_InitialComponentContext() etc on the Java side in this app. The full SVMain() etc will do all that anyway. Change-Id: I555ccd8efbd0260a72fa5904bb6dcd255eed37d4
2013-03-03Android "desktop" app: More hacking on scalingTor Lillqvist
Added a new "mode" for the CommandWheelData, COMMAND_WHEEL_ZOOM_SCALE, where the "delta" is the scale percentage to multiply the curent zoom factor with. Implement in Writer and Calc. But actually, I am more and more startng to think that live scaling of the document view during the pinch/spread gesture will never perform fast enough. Need to go back to the (simple) trick to just scale the BitmapView, and do the actual LO re-zoom only when the gesture finishes. But in order for that to look nicer, need to get rid of the LO UI element clutter around the document, scrollbars, buttons etc. Plus of course need to make sure the LO zooming happens around the gesture center position. Change-Id: I20dfcb4c2a97aacbf7e5b6ea5c24816b237fe687
2013-03-03Add scroll and fling gesture recognitionTor Lillqvist
Not yet passed on down. Also fix a misleading comment. Change-Id: I1e6f79c84b1e13f48e4b2620e44b326fb6fc4ee9
2013-03-03Related to fdo#60724: correct spellingThomas Arnhold
Using the autocorrect list of LibreOffice extras/source/autotext/lang/en-US/acor/DocumentList.xml Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657 Script: http://pastebin.ca/2327716
2013-03-03Do "real" zooming also while the scale gesture is in progressTor Lillqvist
Would work nicely if only it wasn't so compute intensive. Or is it the (temporary hack) constant redrawing that is killing performance? Change-Id: I0b152411a413a818fba7a0f41a3462e423c6ab54
2013-03-03libucppkg1 is needed, for auto-save I thinkTor Lillqvist
Change-Id: Ie4ec4e2518c9e0621b75afe21f22862e3e8bf726
2013-03-03Support an ad-hoc (non-gbuild) Makefile workflow for the Android appsTor Lillqvist
For now, we want to keep being able to just say for instance "make run" in the android app directories. Change-Id: I1898d5466c0df6007fa32b202888bed644fa9489
2013-03-02Try to make the temporary pinch/spread hack look nicerTor Lillqvist
Change-Id: Id293e04c089b9304721f83fb4eb77cffab67cedd
2013-03-02Start hacking on zoomingTor Lillqvist
Change-Id: Ibc9aad490c4616d339e95352a0b8a7f7bed93070
2013-03-01add more stuff to android gitignorePeter Foley
Change-Id: Ibc61098fbde8d253411d834822e3f0c67249c52a
2013-03-01fix android build in separate dirPeter Foley
Change-Id: Id7cf80e1da87a56dee645dc01e64dedc4a8586ab
2013-03-01Cleanups to the android and ios makefileryTor Lillqvist
Also build the "desktop" app from gbuild. Change-Id: I45fc265c9515b22e10bd7644f54dbfa23601e063
2013-03-01Bin some unnecessarily verbose loggingTor Lillqvist
Change-Id: I9c9b2a5405f994f180bd51a3a6c91815d0f70435
2013-03-01Pass touch events on to the ScaleGestureDetectorTor Lillqvist
Note that the listener doesn't do anything with the scale gestures yet, though. I guesss either a new type of VCL event is needed for zooming, or then we could fake entering of Control-+ and Control-- key events (or whatever the default bindings for zoom in and out are). Change-Id: Ib2ba138dd3e7874f85e9fc9fb7ac7198fa6212d3
2013-03-01Loading a test document works nowTor Lillqvist
Change-Id: I02f8ff9c1a2379fe03dff4e5a0dd4a05634d4034
2013-02-28Avoid "Warning: -writer is deprecated. Use --writer instead."Tor Lillqvist
Change-Id: I348df07e6c821969b04fc83b2720d200ffb89f68
2013-02-28Use more logial directory structureTor Lillqvist
The package is org.libreoffice.experimental.desktop so put the source file in src/org/libreoffice/experimental/desktop. Change-Id: I08660962dbd44eb48da0c966e218f49287ab5ca7
2013-02-28Some keys need special handlingTor Lillqvist
Change-Id: Ic2d2d3889d1facbf0042a946fdaf9acd472d0f94
2013-02-28Handle touch eventsTor Lillqvist
Change-Id: I9c9d200731df9ba48ee61f7c97692ed9b9f06648
2013-02-27We need the spell library as soon as we have some text in WriterTor Lillqvist
Change-Id: Ice3eb23f57069043c0c971fce5dfe22aa95c3870
2013-02-27Send text input to the LO codeTor Lillqvist
Change-Id: I28070fb1a8b85c9737d2a78a8a713243ce47dde9
2013-02-26Make it easier to debug the app by sleeping for a while if a property is setTor Lillqvist
If the property log.tag.LODesktopSleepOnCreate is set to "VERBOSE" then sleep after liblo-native-code.so has been loaded to give the developer a chance to start ndk-gdb and set breakpoints. Yeah, a bit silly to overload a logging property like this, but it was the first idea I came up with. Change-Id: I665f87778d083d2d167a5d16f24e2d50b1fba042
2013-02-26Remove copy-pasted imports and commentsTor Lillqvist
Change-Id: I47e61b4ae7d95797f4d17031e9613bb549eb4813
2013-02-26Experiment with enabling text input (not propagated to LO yet...)Tor Lillqvist
Change-Id: Ie9e393dcf23b1b6c219c9bcdf9a3014d7c1cc950
2013-02-25Temporary (one hopes) hack to get the actual view size down to SvpSalFrameTor Lillqvist
Change-Id: I0c2a2301de1b0de71fc6724ff2af73fbf6b406ef
2013-02-25Use actual size of view instead of hardcoded 1000x600Tor Lillqvist
The View size is available only after the view has been connected to the activity, it seems, so move the Bitmap creation to onDraw(). Note that the code in SvpSalFrame::SvpSalFrame() in vcl/headless/svpframe.cxx still hardcodes another (!) size, 800x600. This affcects the size of the desktop-style "top-level window" displayed by the android/experimental/desktop app. I didn't yet figure out the right way to pass the actual view size to the SvpSalFrame. And there is also a hardcoded third (!) size, 1280x750, in AndroidSalInstance::GetWorkArea(), although I don't know what that affects, if anything. Change-Id: I042bf764cd66efa7069c36601170b90d57fa174c
2013-02-22BitmapView can be a member classTor Lillqvist
Change-Id: I172cfc0bcad780e99469ac01c9ba7467befe53de
2013-02-22Rename the package and .apk of the "desktop" test app to avoid confusionTor Lillqvist
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
2013-02-22Rename android/qa/desktop to android/experimenmtal/desktopTor Lillqvist
It's not really a "QA" thing. Change-Id: I85f7b5610ecd409972b7d504bfc567707d35556e
2013-02-21Need the spell libraryTor Lillqvist
Change-Id: I381386852e20bf0424f3189099b10bb33de98bc8
2013-02-21Need the protocolhandler and spell librariesTor Lillqvist
Change-Id: I88b514326be80e56053a28f4a434162fd8d4397b
2013-02-21UNO_TYPES and UNO_MORE_TYPES must contain file: URLs, not pathnamesTor Lillqvist
Apparently it (by accident?) used to work to use pathnames. Change-Id: Icebda427cef645ed53594e179c211d2a9d020583
2013-02-15android: get the desktop demo building again.Michael Meeks
2013-02-15add missing chartcore.Michael Meeks
Change-Id: I069065fedddad0585851629b6c674cd613ad4409
2013-02-15Add other missing libraries.Michael Meeks
Change-Id: I9ab478dc48cc0a0e521641dd89d28a7ee419d242
2013-02-15add missing components.Michael Meeks
Change-Id: I4d7993df862a4a9e9e2c5541f3a6318b2f25e10d
2013-02-15android: share more of the Makefile / build logicMichael Meeks
2013-01-10Kill the ancient StarOffice "patch" conceptTor Lillqvist
For Windows, superseded by Windows Installer patching (i.e., creating .msp files), which is something completely different. (And quite hard to get working... but still a saner approach, I think.) For Linux, many distros use delta RPMs or similar, so no home-grown LO-specific patching mechanism is needed. Remove the -patch and -patchinc command-line options to make_installer.pl and all code that was invoked only when using those. Remove the PATCH and PATCH_ONLY flags in scp2. Remove the patchmsi.dll Windows Installer custom action. Change-Id: I09e949e601a969f88eff60067faa2352f4f89537 Reviewed-on: https://gerrit.libreoffice.org/1605 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Miklos Vajna <vmiklos@suse.cz>
2013-01-06The "ProductSource" (MWS name) makes no sense any moreTor Lillqvist
2012-11-28Add vbaswobj and writerfilter componentsTor Lillqvist
Change-Id: I63c88bcb41a48142f8b3c20ff4d66ae28811411b
2012-11-26android: make this a bit more readableMiklos Vajna
Change-Id: I765458daa808245ec736a3d184ba64c2dcd3a10b
2012-11-26android: extract duplicated casts to helper methodsMiklos Vajna
Change-Id: Ib77731839ad9e46626a7a07d4b2c6c7e32d4bba1
generated by cgit (git 2.34.1) at 2024-08-10 03:15:44 +0000