XAccessibleEventBroadcaster::addAccessibleEventListener test calls the
fireEvent() and the problem is that the event is triggered not on the
print preview itself, but some toolbar button.  This then causes an
accessible event to be broadcast from the print preview too, but only
after doAccessibleAction() returns, some time later from VCL main-loop.

If the test checks the flag in the listener before the main thread sends
the event, the test fails; try to fix that with
XToolkit::processEventsToIdle().

Change-Id: Ia52bdf99cdc349ffb0a03536fba271b792caae0f

Adabas D connector was removed in 8256eb02

Change-Id: Ie142763ac32728c1596c196d919cbe84e6735c96

Intended as a non-functional change.

Change-Id: I1915aad03786540da1a4bfe9031d33f2c2a9b4e3
Reviewed-on: https://gerrit.libreoffice.org/20006Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>

.... and references. This gives numerous false positives as pointers may
be re-set prior to shutdown, so needs a white-list.

Change-Id: I19a011c6f19501cc31b3d9ae76b599296f132478
Reviewed-on: https://gerrit.libreoffice.org/19949Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: Iaaaaca1bcc5f5b6274f54ef4fcd3f35ffe1a9cd0
Reviewed-on: https://gerrit.libreoffice.org/20008Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: Ibae75fc4d843bd38179d4c7afc6ddb532835c7a6

Change-Id: I4128ca0d4ff18f6e0c3c9f8ecad13b69c38c3157

Change-Id: I9a626a11d665b081a7b05db52955598dbd90721e

Change-Id: Icb7573c24c681a8fc0570d61b6a30dab91378eb8

Change-Id: I23ab4d214ed01073f26cbbf2e88732ccde4ebc10

Change-Id: Ia3d1c1ccef53113e50f81a2f93aa157c4e23963b

Change-Id: I08c98ed0f81894444a75adcf7da3a952c7f418cf

... use OUString directly

Change-Id: Ibdf863d7dbbb578e7fe87eac51e3d773a5b05199
Reviewed-on: https://gerrit.libreoffice.org/20009Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

CHECK_GL_ERROR() is now zero-cost in a production build, so no reason
to avoid it.

Don't check for OpenGL errors after glX or wgl calls. They don't
generate OpenGL errors but use the X and Win32 error mechanisms, as
far as I see.

Change-Id: I8f97ef434cbdc89d6e345a247456cfc4a1a82bb6

Change-Id: Ib95118941938af83fed566a085837e17f092017a

Project: translations  7a70fe0c90384e2259a141073d2db4d6bf0038c5

Updated Slovenian translation

Change-Id: Ie3fd52c15d78d44e7e46207a92d7d23bab492814

Earlier, CHECK_GL_ERROR() always called OpenGLHelper::checkGLError().
That function looks up the OpenGL error status using glGetError(),
which might be a not so light-weight operation, and outputs error
information using SAL_WARN(). In a production build where SAL_WARN()
is a no-op anyway, that is fairly pointless.

Change-Id: I2d044bff6128a8ac7739020f8e414d7d3615e8d5

Change-Id: I4a46f7f1ec289f96f9fd1b849317b7548ac29383

Change-Id: I22bf0f7024538ea7a6c2c328a6647d3aeb478141
Reviewed-on: https://gerrit.libreoffice.org/20000Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

On one hand, neither our binary DOC import, nor Word maps the "TOC
Heading" style to something special, and that's how the DOCX import
added that property to some paragraphs in the document, moving the
as-char picture from the first to the second page.

OTOH, the DOCX export filter has a lcl_guessQFormat() function that
explicitly assumes that such a style name exists in Writer document
models, so again it doesn't make sense to handle this style name with
special care.

Change-Id: I3af548930f9683695fc3ad56b486e013f107d61a

Regression from http://cgit.freedesktop.org/libreoffice/core/commit/?id=ccde2360d5c29bb99008cfae5ab3675bee4ca46c
Let's just initialize m_pDoc in ctor

Change-Id: I4fe0f8eff5439b3150c90ac14343aaf8e0a4e43e
Reviewed-on: https://gerrit.libreoffice.org/20004Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I299fa196e960f14e9480e2ac1047bcdcc95b1021

We use textures bound to FBO's for everything in recent times.

Change-Id: I7c9068d75b3653a2ceff0056e2ade1f27955422f
Reviewed-on: https://gerrit.libreoffice.org/19995Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>

Change-Id: I07002fd73fc004439aea75c5aca8ca3700ec1079
Reviewed-on: https://gerrit.libreoffice.org/19996Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

It was possible to set a tooltip for a certain toolbar entry.
However, this hasn't been used since that tooltip needed to be repeated for each occurence of the same command.
Instead, a TooltipLabel property has been introduced lately (see 9c2f197e).

This doesn't affect extensions (They have their own format to specify toolbars).

Change-Id: I0f0fd05b310bb49dd5b4123e31d3e7fec997dd15

Change-Id: I037f4a293c64071306b782a156162735a2658e23

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

Change-Id: I6772cce10d157421d983d6b93efb52bf8b95f5b8

Change-Id: I79c22e0507c5eba8b5e28721de3279131aececc9

Change-Id: If7e3ef81cad8974bc54f359096e3ecc700fa62d6
Reviewed-on: https://gerrit.libreoffice.org/19984Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Change-Id: I85000851f82ea7cdc4b536683adbc8570de9af7e

This fixes a buffer overflow writing over the end of pCaretXArray,
which can happen e.g. when drawing mnemonics in the password dialog.
Based on a similar calculation of nCurrIdx found in
GenericSalLayout::GetCaretPositions().

Change-Id: I7d723cf8cfaeb66f340c7d9ea5b3bc728c6d6209
Reviewed-on: https://gerrit.libreoffice.org/19385Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I3bb2764b625d44f6e0cecbdde3363440faef63b5

The build works fine with these now, and produces no (new) warning.

Change-Id: I3e5aad7baaec172ee4d2b50ea66876bdb7e9cac5

Change-Id: I22c66755e8e5ede01cf3e5f21c910f759b55de7a

Change-Id: Ie0c91e739ee7a3bda55fd6dd45aa79c6b75675d1

This may happen if the last RPN token is put and the function has a
ForceArray parameter but now again would be wrong if not all parameters
are ForceArray.

Change-Id: I890fb6b5b88337033cfcf2e8189371ee39461205

Change-Id: I08c4cc689016708f4c219f36492bf827111bbc30

Change-Id: I5874a7fea97311b0e69dbeae8923517a08b63c9a

Regression of b5cd11b4

It was always wrong to propagate ForceArray already if a function had a
ForceArray parameter *somewhere*, we need to do this per parameter
instead.

Change-Id: If188d45366279d9a7bf641edc7e4dd7095d6d035