As new 'edit' group because they are not needed in view-only
TiledLibreOffice_app. Although, probably there are more components
in 'core' which should be in 'edit' too, who knows, sigh.
Change-Id: I1efebc9884662a5d25744a3414717aa410350ef4
Also remove extended_core group. If something from there will be
needed, we will add it another way.
Currently only android/experimental/desktop/Makefile and
ios/CustomTarget_TiledLibreOffice_app.mk are known to do something.
Change-Id: I99936075e35ce98d684581838c0a19dccd83f942
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
