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

... file format by default if the requested filter does not exist.

Much better to write an error message and do nothing.

Change-Id: Ie5404772e7aae5751126bd4c2784b58177804448

JunitTest_sc_unoapi crashed when accessing a disposed ScTextWnd from
~ScAccessibleEditLineTextData(), but the ScTextWnd::dispose() would also
call ScAccessibleEditLineTextData::Dispose() and clear mpWindow, so it
seems impossible to observe a disposed ScTextWnd in the dtor?

Change-Id: If571ee61d9a29601acb1de552ec1b9cc36d0d51e

Change-Id: Ie45e626aad55a8174a53b769a98601bf54dedf65
Reviewed-on: https://gerrit.libreoffice.org/19979Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I4d02024fd80ad85c8c3ecd830dcc5c4b49ad2014

Change-Id: I59147583c74e7211ac56d75468501f328122ba0f

Change-Id: I850a207aebdf2a0f85f1ae75bb6b9a1532b3b4a6

Change-Id: Iffb3681458aeee7b374d1836158e30b6fd488122

Change-Id: Iee7124259cadc1db416e8aedc5b4e87f75ba9d21

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

Change-Id: Ida1447bad7f81ebfcc0da1e8278a74c11a139afe

Change-Id: I5514bf16446fa4e4c498a6bc1df77e4f59565ee1

Change-Id: Id1d6166ee8c1c3558746da1d7bb5ad2163a87845

Change-Id: I083dfbb768df0ba2a6bd6a396cf33ab1e2e09f4b

Change-Id: I2c4de63330a18c4354293d0220e5320eda7d67e4