| Age | Commit message (Collapse) | Author |
|---|
|
It seems that on iOS, where we don't have any Java, Python, BASIC, or
other scripting, the only thing that would use the C++/UNO bridge
functionality that invokes codeSnippet() was cppu::throwException().
codeSnippet() is part of what corresponds to the code that uses
run-time-generated machine code on other platforms. We can't generate
code at run-time on iOS, that has been known forever. Instead we have
used some manually written assembler to handle it instead. We used to
have a Perl script to generate a set of code snippets for different
cases, different numbers of parameters of the called function and
whatnot, but that went away at some stage some year ago. (It is
unclear whether that broke the C++/UNO bridge on iOS, or whether the
stuff continued to work even after that.)
Anyway, this handwritten assembly, or the manual construction of
internal data structures for exceptions, or something else, seemed to
have bit-rotten. Exceptions thrown with cppu::throwException() were
not catchable properly any longer.
Instead of digging in and trying to understand what is wrong, I chose
another solution. It turns out that the number of types of exception
objects thrown by cppu::throwException() is fairly small. During
startup of the LibreOffice code, and loading of an .odt document, only
one kind of exception is thrown this way... (The lovely
css::ucb:InteractiveAugmentedIOException.)
So we can simply have code that checks what the type of object being
thrown is, and explicitgly throws such an object then with a normal
C++ throw statement. Seems to work.
Sadly the cppu::getCaughtException() API still needs some inline
assembly in the C++/UNO brige. That seems to work though, knock on
wood.
This commit also adds a small "unit test" for iOS, copied from
cppuhelperm to ImplSVMain(). Ideally we should not copy code around of
course, but have a separate unit test app for iOS that would somehow
include relevant unit tests from source files all over the place.
Later.
Change-Id: Ib6d9d5b6fb8cc684ec15c97a312ca2f720e87069
Reviewed-on: https://gerrit.libreoffice.org/60506
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I78571f8494a13f6f8c07f9aee2bf6f8144a48ed2
|
|
Change-Id: I1310cb8f5f543f49f9667ee10cb26c9809df259e
|
|
Change-Id: Icea9a5e4796dda288fafcd478a769fa7087baab2
|
|
Removed the need for a xcode project to prelink
all LO libraries.
Change-Id: I16d38ae0205e73de59b1cf3abdbbb8d4fea6d24c
|
|
LibreOfficeKit.c was compiled with an xcode project and not like
all other sources. Changed to use clang with same switches as
rest of LO.
Separated resource generation in own makefile
Removed project LibreOfficeKit which was responsible for prelink.
Change-Id: Iaf9fbb4b652501af0b7f3643ed3efcc2ed93b611
|
|
Cleaned up custom targets.
Change-Id: I11ef1cb6d129722ac206b298c6ad15c00da5c433
|
|
Moved generation of the xcconfig files out of configure.ac
and into the regular ios make.
Change-Id: If675eac9e86c4c4a0ff98f84815b0a83555d90a8
|
|
Added general support for arm64
Removed experimental/prototype from normal build
Change-Id: I832256c72fbd408084bc802440343c874e7e6d28
|
|
Retired TiledLibreOffice, replaced by the prototype.
Newer development takes place in LibreOfficeLight
Change-Id: I170ea49086f860bda9c86aaa8ca7de00907dad67
Reviewed-on: https://gerrit.libreoffice.org/35483
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Integrated LibreOfficeLight into gbuild.
added lo.xcconfig and Resources (needed to link with LO and run LO)
added swift --> C interface for LOkit
add known commands from JS client
added C++ condition in LibreOfficekitInit.h (inline no good in a C file)
Change-Id: I19ebe8912546408bf701c96c0c63541d6e37cad8
Reviewed-on: https://gerrit.libreoffice.org/35430
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@libreoffice.org>
|
|
The prototype project is a minimal project, with
LibreOffice kit.
The purpose is to check if it can build, and be foundation
for other projects.
The project have been updated to use the newest xcode
Change-Id: Iac277629bc749bcacb83fb056c70a9ec46c8156d
Reviewed-on: https://gerrit.libreoffice.org/35286
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
It seems abandoned and hasn't work since we switched to tiled
rendering anyway. And the need for the special single tile at a time
rendering test mode is mostly gone now, when tiled rendering can be
tested with the TiledLibreOffice app, I think. So no need to slow down
a "make" by building the MobileLibreOffice app, too.
Change-Id: I7b0afd3b35ff2ed0fb72f2c150abb25548a5546d
|
|
It hasn't worked since the switch to tiled rendering anyway, and we
use the 'TiledLibreOffice' app for testing now.
Change-Id: I8137b8390c020ec4e6826e40e9cda69810f8318f
|
|
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
|
|
Change-Id: If486cf470583205763722766da57303de904b321
|
|
Change-Id: Iefb00e72f2700503ea33a28c9f7e2150f0d1e06e
|
|
error: The project 'MobileLibreOffice' does not contain a scheme named
'MobileLibreOffice'
Change-Id: If722a222407f1e85086d9d89d7863be7a5c8368e
|
|
Change-Id: Id03bf8002902f1adec57356601b28ab2c743df2a
Reviewed-on: https://gerrit.libreoffice.org/6476
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
No, it isn't any closer to being "ready" despite the name, but still,
using the current approach, it clearly isn't restricted to be just a
viewer.
Also drop the verbose LOViewer prefix from class and file names in it.
Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
|
|
The Viewer app is intended to eventually resemble the experimental
Android DocumentLoader app.
Build using the gbuild mechanism, which is also invoked from an Xcode
project. This seems to work out fine, the resulting app installs at
least on the simulator, and you can debug all the LO code involved
even if Xcode (obviously) has no knowledge of the LO source
files/classes/etc.
Change-Id: Ic96178d80b8d6467cac969b29e37f0d39513acf9
|
