Change-Id: I1cdf56df10516f01ca091043b6a01bc14095413a
Reviewed-on: https://gerrit.libreoffice.org/15242Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I6420205d87c85c88137b8fc11fa16e313f2fcb35

Resurrect the special hack "lcl_SubtractFlys" that effectively paints
"lower" flys on top of "higher" flys, defying the z-ordering, if the
lower fly is *anchored* in or at the higher fly.

It turns out that this is not obvious to emulate in any other way that it
is currently implemented:

One idea would be to split up painting of the fly background from the
foreground, by creating 2 different view objects per fly as children
of the SdrPage when decomposing it in svx; but the problem is, they will
be ordered in z-order of the flys, and the point would be to paint the
backgrounds first and in a different order, call it "anchoring order".

What that order should be is hard to tell, there is a conflict between
the defined z-order and the flys that are part of one "anchoring
hierarchy" and should have their backgrounds re-ordered, because
entirely unrelated flys that could belong to different "anchoring
hierarchies" but overlap the first ones may result in a cyclic ordering.

Painting one "anchoring hierarchy" recursively would not get
z-order of flys from different anchoring hierarchies right.

Another difficulty is that heaven-layer backgrounds would need to be
painted before hell-layer ones.

Another aspect of the lcl_SubtractFlys is that it entirely ignores
drawing shapes; only Writer's own flys are handled.

Since none of the above makes much sense, we clearly want to
deprecate the lcl_SubtractFlys rendering.

Introduce a new compatibility flag "SubtractFlysAnchoredAtFlys" so that
the legacy rendering is only active for legacy documents, while new ones
remain free from its taint.

(regression from 6e61ecd0)

Change-Id: I710fe79710b89c8f865ebb7162e14713aac6cc4a

Change-Id: I3d496f78fd60a3a47cc62d4237f31e5e131a9692

Change-Id: I7d464cf33b0bfd29f4f6f750abcab2e59257788d

Most likely it was cleared by another thread while this one showed the
"no JRE" dialog.

Change-Id: Ib0e74c73a510f52778163ad24c20d7ae835ced11

Backported from
http://bugs.icu-project.org/trac/changeset/36724
http://bugs.icu-project.org/trac/changeset/36727
http://bugs.icu-project.org/trac/changeset/36801

Change-Id: Idd85c3344e3ef86e390341038f53ad2a398b3fa3

Change-Id: I3a249d1ee4a49dfc66d7d6052803b0896ae42d39

Change-Id: I4472eb296de3fcf4832750229c67acb0d846cbb6

Change-Id: I8594ad75b82ea4d8b5178de7e1f44e7402b22fda
Reviewed-on: https://gerrit.libreoffice.org/15225Tested-by: Yousuf Philips <philipz85@hotmail.com>
Reviewed-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: Ic292b2ba03496e9f7a4cce7a0c0284d25ec7f6df
Reviewed-on: https://gerrit.libreoffice.org/15226Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: I53529d657faa735b787852f1b1ffe082f03154ce
Reviewed-on: https://gerrit.libreoffice.org/15227Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: Ife3e805b95bede7be5d436abab925b35e717ee5e

Assume m_vEntries.size() == 2; assume first element (nPos == 0) is m_bActive,
gets removed, so m_nActive would have stayed at 0 and m_bHasActive at true; then
assume second element (again nPos == 0, due to the removed element) is m_bNew,
so nPos <= m_nActive is true and m_nActive gets updated to 1 (and m_bHasActive
remains true); then selectEntry(nNewPos) (nNewPos == 0) would have tried to
reset m_vEntries[1]->m_bActive but now m_vEntries.size() == 1.

Change-Id: I31d3bbe97ca99f880aa99bdea015f7c0457f8331

Change-Id: I5ce2f528ae4a243ea8402c787b5c77cf75052d2e
Format: "Slide 2 / 3" changed to "Slide 2 of 3 (1)".
Reviewed-on: https://gerrit.libreoffice.org/14806Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Katarina Behrens <Katarina.Behrens@cib.de>

SwDoc::AppendDoc() inserts nodes from an other document, and before
doing that, it inserts a page break at the end of the document. In case
there are marks at the end of the last paragraph, the insertion of the
page break moves them to the next page. This is a rare situation, but
happens e.g. when the source document is an empty one: then MM puts a
mark at the first paragraph of each inserted MM part, and then the first
paragraph == the last paragraph, so the mark of the only paragraph in
the document gets moved to the next page.

This is a problem on its own, but is detected by the SwIndexReg dtor
when that empty paragraph gets deleted later in SwNodes::Delete() called
by SwDoc::AppendDoc(), resulting in an assertion failure.

Triggered by commit a305a2c9 (use
bookmarks to mark mailmerge parts in a mailmerge document (fdo#80823),
2014-10-20), these not adjusted bookmarks were not detected before.

Change-Id: I89775b477a2fd3182b2bc87144aed2bfe7912aff

Change-Id: Ic19ef6465036050b3b72949af65e23f8dde3afcf

This also employs smart pointers for some variables in Test, and
drops unused code which b3edb241
left behind.

Change-Id: I6c19d4b8f65b057bad2106c3e9d081446a2619a1
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: Idb2e46fcaa080d6763d2e3ed963f7673a2353eb2

Change-Id: I049aa3f5be42c520f824ec62943c37e8ffac78ad

Change-Id: I4b13d3b7d74690401234dfa30c8c1b6647820b6a
Reviewed-on: https://gerrit.libreoffice.org/15216Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: I5a159be0c342b778730cedb0fe35843c2c368c97

and fix up some confusion in SC and STARMATH about which constants to
use

Change-Id: Ib75bc78a24bd2fad6ec6d7c94c4c1ad7dc222c1a

and fix some dodgy usage in /sc in the process

Change-Id: Ia2bee267df31aba431fc8cb81195bb83e5b64deb

Change-Id: I424a1c71429078f8f83f8f0138c6e12567628ef8

Change-Id: I0a1163b54601932957b0217894173aeadbf34e6e
Reviewed-on: https://gerrit.libreoffice.org/15223Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>

Change-Id: I79a357a51a3d98774745001d5f99b045ef964255
Reviewed-on: https://gerrit.libreoffice.org/15218Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

Change-Id: Id969145f25e99047d21e9ea3c97323274168cf64

Change-Id: I0b868edad579f9ccf46f6d9f6015086557e528da

Change-Id: Iaa0c751f101df6db25e9fca9123b81ac63033159

Change-Id: Iee8c093f5aa8306c3e5336d6dd5e801df6df87a4

and de-ifdef-per-platform the patch makefile so an upgrade attempt on one
platform tests the patchs applying on all platforms

ubsan.patch.0 was effectively applied upstream while need
to add http://rt.openssl.org/Ticket/Display.html?id=3650 to build
under windows

Change-Id: Ieffd9bc3dd861a94a083d8b6b8d4117bba7f527c
Reviewed-on: https://gerrit.libreoffice.org/15183Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

moving to a new row will set the new type, but initially
its not set because the ListStore property was set after
the model is connected to the database so at the initial
connection time there isn't a available set of values
to map the row to.

So move that connection code from general.cxx to datman.cxx
and put it before the connection is established

we can then remove the intermediate aBibTypeArr list and
those resources then need to be global bib ones.

Change-Id: I12276c3df9955ec399e1b5de6d0836c69ebb1ebb

Change-Id: Iebdc66d1c994e3702efa5609fb36b5b2b9273c86
Reviewed-on: https://gerrit.libreoffice.org/15217Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>

...as follow-up clean-up after 71fefe1d "Change
'blink times' to be of type sal_uInt64 and thus consistent with
Timer::Get/SetTimeout since 9c7016b5 'Scheduler:
Changed uLong to uInt32/uInt64.'"

Transitively meant to change quite a number of further time-related places from
sal_uLong/sal_uIntPtr to consistently use sal_uInt64.

Change-Id: I38eb493943906356138bf58eb098d2f54a3dee34
Reviewed-on: https://gerrit.libreoffice.org/15214Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

Ensure that only desired tokens are obtained and the resulting new token
is actually the current one upon return.

Change-Id: I624c324b861d8658accf3285cad2cfc5a598b450

Change-Id: I1263f190d769254949701b3a257b2af5d6ea61a2

Change-Id: I73109e5a862b2f4bc456dff512bddf5d23586a6d

Change-Id: Ia4a52a5e605474738983d48a925b6b3ba90877d4

but the PanelLayout didn't

Change-Id: I38a8975f1488fa2a2ffe91b66745e1a1c6c48a28