In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
When calling XUnoTunnel::getSomething(), the function must drop the
CPython GIL to avoid deadlock since there are implementations of
XUnoTunnel that acquire SolarMutex.
Change-Id: I51ffce9bdee9a51c932902e77856f865eae81d2a
Now that we have default values for Exception constructor params,
remove lots of boilerplate code.
Change-Id: I620bd641eecfed38e6123873b3b94aaf47922e74
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
It's not very efficient, because we generally end up copying it twice -
once into the parameter and again into the destination OUString.
So I create a clang plugin that finds such places and generates a
warning so that we can convert them to pass-by-reference.
Change-Id: I5341a6ea9e3190f4b4c05c42c85595e3dcd83361
The bug in question crashed LibO when inserting a group of cells.
This bug was quashed, per se, by commit
07e2c31831ad265b018e5fdf59bdde048fbb4d35, but it occurs to me that at
least the particular functionality of inserting a group of cells could
use more testing.
Change-Id: Icdbfff86fb0265eef325bcc94d9fc9f3e9e38413
* see the mail thread starting at
<http://lists.freedesktop.org/archives/libreoffice/2014-February/059548.html>
"Testing/Working on PyUNO?" for a rationale
* run the tests via top-level "make PythonTest_pytests" or "cd pyuno && make -rs
PythonTest_pytests" or similar
* see the documentation in pyuno/PythonTest_pytests.mk for adding tests to the
framework
Change-Id: I6a2a9e60b3294cd649f9cccbaffbd3f6bd79ecff
