summaryrefslogtreecommitdiff
path: root/android/experimental/desktop
AgeCommit message (Collapse)AuthorFilesLines
2013-05-02android: Keep the images_tango.zip name as isTor Lillqvist1-1/+1
Not sure why I used to store it as images.zip. Probably just a mistake. The code uses the images_tango.name.zip when trying to open it. Sure, no toolbar with images is displayed currently anyway, so having this file in the .apk is pointless, but there has been talk of reverting the disabling of toolbars, sigh. Change-Id: I12dfd3abe8f329d660b518f6b37904aa00423bc2
2013-05-02Adapt to library name changes for Android, tooTor Lillqvist1-1/+1
Change-Id: I6da1f38c5a9693c13ef841442cbef017d388416a
2013-04-30android: remove lotus word pro filter - bit optimistic.Michael Meeks1-2/+0
Change-Id: I08bbec95db2ae9bc7226cd5ca1cc7b81c235a26f
2013-04-24Adapt to changes in type rdb file locations and namesTor Lillqvist1-3/+2
The old bin/ure/types.rdb was just a duplicate of bin/udkapi.rdb. There is no bin/types.rdb any more either. We have just udkapi.rdb, offapi.rdb and oovbaapi.rdb now. Change-Id: Idd0911f1d4d48f172af159b852918d429f17cc92
2013-04-23The file names of many UNO components have changedTor Lillqvist1-7/+7
Change-Id: I18f90b058e40ca15164fd3e8c33bc904b930981d
2013-04-19Small refactoring of the Android "desktop app" code, no functional changeTor Lillqvist3-27/+18
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-04-14fix android buildDavid Tardon1-1/+1
Change-Id: I97903559e1f6ef48476a74a674c0832d9cb44640
2013-04-12Add more componentsMichael Meeks1-0/+36
Change-Id: I3ea18b4a075516f3c098fad5d63466f20bf0b494
2013-04-11Get soffice.cfg from its new location for Android, tooTor Lillqvist1-2/+2
Change-Id: I2d65b51ec9a223994d39dc9433d1290b44422e1d
2013-03-27Use proper version numbersTor Lillqvist1-1/+1
Change-Id: Ib0284c3fe63636e42b2e72ab76b02a8197c837e0
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 Lillqvist2-13/+47
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-03libucppkg1 is needed, for auto-save I thinkTor Lillqvist1-0/+2
Change-Id: Ie4ec4e2518c9e0621b75afe21f22862e3e8bf726
2013-03-03Support an ad-hoc (non-gbuild) Makefile workflow for the Android appsTor Lillqvist1-1/+3
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 Lillqvist1-2/+11
Change-Id: Id293e04c089b9304721f83fb4eb77cffab67cedd
2013-03-02Start hacking on zoomingTor Lillqvist1-2/+40
Change-Id: Ibc9aad490c4616d339e95352a0b8a7f7bed93070
2013-03-01fix android build in separate dirPeter Foley1-1/+1
Change-Id: Id7cf80e1da87a56dee645dc01e64dedc4a8586ab
2013-03-01Cleanups to the android and ios makefileryTor Lillqvist1-1/+1
Also build the "desktop" app from gbuild. Change-Id: I45fc265c9515b22e10bd7644f54dbfa23601e063
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/+0
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 Lillqvist1-4/+38
Change-Id: Ic2d2d3889d1facbf0042a946fdaf9acd472d0f94
2013-02-28Handle touch eventsTor Lillqvist1-2/+33
Change-Id: I9c9d200731df9ba48ee61f7c97692ed9b9f06648
2013-02-27We need the spell library as soon as we have some text in WriterTor Lillqvist1-0/+1
Change-Id: Ice3eb23f57069043c0c971fce5dfe22aa95c3870
2013-02-27Send text input to the LO codeTor Lillqvist1-0/+5
Change-Id: I28070fb1a8b85c9737d2a78a8a713243ce47dde9
2013-02-26Make it easier to debug the app by sleeping for a while if a property is setTor Lillqvist1-3/+15
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 Lillqvist1-162/+1
Change-Id: I47e61b4ae7d95797f4d17031e9613bb549eb4813
2013-02-26Experiment with enabling text input (not propagated to LO yet...)Tor Lillqvist1-5/+59
Change-Id: Ie9e393dcf23b1b6c219c9bcdf9a3014d7c1cc950
2013-02-25Temporary (one hopes) hack to get the actual view size down to SvpSalFrameTor Lillqvist1-3/+5
Change-Id: I0c2a2301de1b0de71fc6724ff2af73fbf6b406ef
2013-02-25Use actual size of view instead of hardcoded 1000x600Tor Lillqvist1-3/+7
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 Lillqvist1-8/+5
Change-Id: I172cfc0bcad780e99469ac01c9ba7467befe53de
2013-02-22Rename the package and .apk of the "desktop" test app to avoid confusionTor Lillqvist7-28/+24
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 Lillqvist11-0/+928
It's not really a "QA" thing. Change-Id: I85f7b5610ecd409972b7d504bfc567707d35556e
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-21 01:49:24 +0000