Put cui and spl into extended_code and ignore the rest.
Also change DocumentLoader and LibreOffice4Android to use only
extended_core and writer as all the ios apps do, without knowing what is
really needed there.
Change-Id: Ic6a256ea47cc96132c0e7658d6ef2838b295ca71
It still seems to work for me.
Probably we do not need more components, but it's small enough for now.
Also add uui into 'core' group.
Change-Id: Ifadea8aa819ed17bbd021a0fa2373e6287e06446
Group logic from include/osl/detail/component-mapping.h has been
duplicated here for now.
The plan is to reuse this for iOS too if possible.
We don't need component-declarations.h now, which is good because
the list of implementation constructors is going to grow a lot over time.
Also, something needs to be done to avoid component-defines.h.
--constructor parameter was removed because it was not used
and also does not make sense.
__attribute__ ((visibility("default"))) is removed too.
Change-Id: I5e3f988800303d31e1d78220cbd25339bcbc482a
No one says this is the only good classification.
Quite possibly it's not even a good one, but at least something.
Change-Id: I81178314222f9f63708a83b262ff8ef73a1d9467
...to directly call constructor functions of ComponentContext-based C++
implementations of (non-single-instance) UNO services. The case where these
calls would need to be bridged across different environments (e.g., from gcc3
to gcc3:affine) is not yet implemented.
bootstrap.component and expwrap.component are adapted accordingly as a proof-of-
concept (which had previously been adapted to use the prefix="direct" feature,
which may become unnecessary again in the end, depending on how to handle
single-instance services/singletons). More to follow.
Change-Id: I18682d75bcd29d3d427e31331b4ce8161dbb846d
It's not terribly nice, but, hopefully, better.
The hope is that one day, lo_get_library_map will be no more.
In lo_get_implementation_map we can specify more precisely what to link
into the binary.
Change-Id: I99a1854fbae05be2f70302cc56bea88e522ec129
Demonstrating on expwrap library.
There is hope, this will bring code size savings for mobile
platforms, where we don't need every implementation.
Change-Id: I3519fb6148fd7a47ed9df092c73779ea6add552f
They were used to build metrics for printer built in fonts, which was
dropped in the previous commit.
Change-Id: Id9fb3108facec61eb6de0a2d16546f1187465e50
Reviewed-on: https://gerrit.libreoffice.org/6861
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
With this, these apps can be used even if /data is something like 128MB,
e.g. on normal phones, not tablets / emulators.
Change-Id: I7c8f2787b6395e98e8065e2e207aa09d9a2f39b3
Acked-by: Tor Lillqvist <tml@iki.fi>
I got scrolling to respond to the JNI scroll method call. (This is not yet
the gesture I want to implement (scroll by pixels), but at least it’s a
start.)
At first I tried to do some hacking in the C++ part, then found the problem
was in the Java parameters, which set the mouse whell delta too big. When
passed the value 1 or -1 to the Y value of AppSupport.scroll(int x, int y),
the scrolling is reasonable.
Change-Id: Id8fa0ada1a035760b7b05bf21325d0e51ef28fdc
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
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
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
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
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
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
