The executable of the LibreOffice app (which as such at the moment
doesn't work, since the tiled rendering changes) is built using
gbuild, and thus we can't generate the native-code snippet in the
CustomTarget that builds the app bundle, but need it already when
building the executable. This is one wayt to handle that.
Change-Id: Ifdab40c970e93b1f2608cefc637df8a8e5396efe
This allows us to get rid of component-declarations.h and
simplify component-mapping.h.
For new, converted, implementation_getFactories, adding one line into
native-code.py should be enough to make them available in application.
Change-Id: I042320e5b7f8a9aa9f02b77d2bdd07cf9a690ee6
Avoid an implicit upper limit on the value calculated (and displayed) by
keeping a counter, too, for each slot in the array.
Also edit a comment, as I now have a better understanding of how the
tiling works.
Change-Id: I5df4076917a244f73f27b66f4983f17ce95b9df7
Running dsymutil takes much too long to be bearable during
development. But when building for actual release we do want a
separate dSYM of course. (Of course none of the current iOS apps in
the source are intended to be actually "released". But add this logic
just for completeness.)
Change-Id: Ibb5037d6926e969a891269d6c9d86232bc01cb3c
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
I had to add some horrible hacks to make sure the test doc has been
loaded into a Writer shell before retrieving its size and being able
to render it. Obviously some better solution is needed. But this is
just a testbed to get some profiling data.
The app is built using an Xcode project, and in gbuild through a
custom target based on the MobileLibreOffice one. Setting up the
various files used (or not used...) at run-time should really be
factored out from the CustomTarget files.
Change-Id: I1711b0cae9d28a09b73476b2d37d98b1820c9943
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
ARCHS tells Xcode to build the architecture for which the LO code has
been built. The CFLAGS properties make sure the same -D flags are used
as for the LO code.
Change-Id: I3c8af0ff9fba7d0b4eddbc0af9aad44fb385314c
Possibly quite broken intermediate commit. But anyway, now it is
possible to render the tile diretly to a CGContext. Can be seen in
the MobileLibreOffice app when build in the Debug_tile_tester
configuration. See touch_lo_draw_tile() in viewsh.cxx. Unfortunately
the old plain LibreOffice test app is now broken, though, and
displays nothing at all.
This refactoring and hacking in vcl was done in a quite ugly fashion,
with ifdefs etc. But trust me, I did try, several times, for many
days, to get where I wanted in an elegant and clean fashion. But doing
it cleanly meant not being able to actually build it for days while
trying to figure ut which bits go where and which class should be
split into what base and derived class(es), and it was too much for my
limited brain capacity. I just couldn't juggle all the vcl class
structure in my head, especially as I don't have any good
understanding of the general design of it all.
Change-Id: Ia59d6a9cce15a63e63f94e8d8574bef21993fb1f
Keeping this stuff working is hard. How did I not notice this before?
I need to make clean more often I guess.
I edited the project.pbxproj file manually as I didn't fully get it
how to set up the wanted handling of this file in the Xcode GUI. So I
just copied the handling of offapi.rdb in project.pbxproj (with
different ids, of course).
I really much prefer doing this fully in Makefiles, as in
CustomTarget_LibreOffice_app.mk.
Change-Id: Ifc4f2481f7a9d1562be6f91714ed38c82cdd5eb0
The intent hopefully is that the MobileLibreOffice project should be
buildable in a freshly cloned or otherwise clean tree, where Xcode has
not been used interactively (which automatically creates a scheme for
each target, it seems).
Change-Id: I690513ecf54bb824dd3c3b0ef1735cc5cdff6d60
Otherwise we get tons of (as such, in our case harmless) warnings from
the linker about mismatches.
Change-Id: I826d9e065bae59cdd213131163b31b2099806dd3
