summaryrefslogtreecommitdiff
path: root/android/experimental/desktop/src/org/libreoffice/experimental/desktop/Desktop.java
AgeCommit message (Collapse)AuthorFilesLines
2013-04-19Small refactoring of the Android "desktop app" code, no functional changeTor Lillqvist1-22/+14
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
2013-04-19Make the use of SAL_LOG=+WARN+INFO optionalTor Lillqvist1-1/+6
Change-Id: I6af17a7745f4de88b4933e93b77eda1050760794
2013-04-19Minor comment changeTor Lillqvist1-5/+8
Change-Id: I14e9b86c23ff000df2339a37ba78a11cc319f27c
2013-04-19Attempt to avoid popping up keyboard after panningTor Lillqvist1-1/+5
Change-Id: Ie5639ea5a2c50e54ab880ac850287de07ff69959
2013-03-07Try to make the scrolling and zooming actions snappierTor Lillqvist1-17/+18
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 Lillqvist1-10/+38
Change-Id: I74f1d7feb935be65629bdbd7464f9882229948e5
2013-03-07Handle damage tracking and redrawing properly in the "desktop" Android appTor Lillqvist1-9/+42
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 Lillqvist1-13/+8
Change-Id: I1d825c39cde67c204110b4a787b3ffb290331fe5
2013-03-05Rework scaling once moreTor Lillqvist1-23/+17
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 Lillqvist1-1/+2
Change-Id: I053f7d4a17aec9c8b24b92a40de635c71492a3dc
2013-03-03Android "desktop" app: Simplify bootstrapping on the Java sideTor Lillqvist1-35/+3
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 Lillqvist1-8/+12
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 Lillqvist1-7/+25
Not yet passed on down. Also fix a misleading comment. Change-Id: I1e6f79c84b1e13f48e4b2620e44b326fb6fc4ee9
2013-03-03Do "real" zooming also while the scale gesture is in progressTor Lillqvist1-19/+7
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-02Try to make the temporary pinch/spread hack look nicerTor Lillqvist1-2/+11
Change-Id: Id293e04c089b9304721f83fb4eb77cffab67cedd
2013-03-02Start hacking on zoomingTor Lillqvist1-2/+40
Change-Id: Ibc9aad490c4616d339e95352a0b8a7f7bed93070
2013-03-01Bin some unnecessarily verbose loggingTor Lillqvist1-5/+0
Change-Id: I9c9b2a5405f994f180bd51a3a6c91815d0f70435
2013-03-01Pass touch events on to the ScaleGestureDetectorTor Lillqvist1-0/+2
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 Lillqvist1-2/+2
Change-Id: I02f8ff9c1a2379fe03dff4e5a0dd4a05634d4034
2013-02-28Avoid "Warning: -writer is deprecated. Use --writer instead."Tor Lillqvist1-1/+1
Change-Id: I348df07e6c821969b04fc83b2720d200ffb89f68
2013-02-28Use more logial directory structureTor Lillqvist1-0/+295
The package is org.libreoffice.experimental.desktop so put the source file in src/org/libreoffice/experimental/desktop. Change-Id: I08660962dbd44eb48da0c966e218f49287ab5ca7