We dump the library's symbols we're trying to stubify, and then
assemble another library that looks just like it, except with all
of it's innards sucked out.
We also use pkgconfig to find all the relevant dependencies and
to build an entire library tree.
Catalan (Valencian) has no ISO 639 code assigned and the UI localization uses
the ca-XV hack where XV is of the reserved ISO 3166 user-assigned range. This
should not escape to document content therefor internally a replacement to
ca-ES is done for all locale attribution. For the UI localization to be
distinguishable under Tools->Options->LanguageSettings->UserInterface this
needed a special handling to allow Catalan (Valencian) again.
Setting a page-anchored object to cell-anchored didn't show the anchor
immediately until you unselect the object and re-select it. Same for
the cell-anchored to page-anchored direction.
This commit fixes it.
Currently on File->Properties we display "LibreOffice 1.0 Text Document"
etc. for OpenOffice.org XML format documents, which is wrong: these
should not be re-branded.
This should fix the spurious segfaults caused by running the test while
the library is being overwritten in parallel that cannot be reproduced
by just running the test.
CLASSPATH is supposed to show where to find the classes needed by Java
programs running at build time. The -cp switch to javac tells where to
find classes referenced by the code being compiled. These are
different things. (But it doesn't seem to have mattered much in our
build system.) So use T_CP instead, named in the same fashion as
T_CXXFLAGS etc.
But... for some reason this change, which as such should be just more
or less cosmetic, also fixes a build problem in the "scripting" module
on Windows, seen by Noel Grandin
(http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/19016
) and me.
The old way was that an error cell was evaulated as having a value of 0.
The error cell also showed up as blank in the popup. Using the error
string is much more intuitive (and some users apparently want this
behavior).
We were supported to convert XML chart data range representations
with a hard-coded ';' as the range union operators, but incorrectly
using UI configurable range separators. This caused charts with
series that consisted of multiple ranges to be imported correctly in
locales where the range separator (which re-uses the function argument
separator) was something other than ';'.
BTW I plan to remove this "always use Calc A1 syntax" restriction in
future versions.
During Paint() in ScMultiTextWnd::InitEditEngine(),
ScTabViewShell::GetActiveViewShell() may return a view shell that does not
correspond with the document to be repainted if another document was opened or
when switching between documents. Prevent creating an EditEngine with wrong
SfxItemPool.
