Change-Id: Iae68359bb0e17412300db74ffdceed4341c5288e
Reviewed-on: https://gerrit.libreoffice.org/31835Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I290710ee5242e33c4ce7b46a44068fcd54c245a8
Reviewed-on: https://gerrit.libreoffice.org/31840Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Project: translations  ef59b48c9927301075cff0e2729b5d0a7ea214ed

update translations for 5.3.0 beta2

and force-fix errors using pocheck

Change-Id: I50100798b84da2969535c4f558dd60463b30108e

Following https://cgit.freedesktop.org/libreoffice/core/commit/?id=8228227168a7eb3ebf14629bec87f01536c23970
an OSL_ENSURE has been replaced by an assert
I expect to find a bunch of these cases, so this one is the first I deal with.

Change-Id: If2d3c2f5cff9d306918adc200146113eb54f26c8
Reviewed-on: https://gerrit.libreoffice.org/31841Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: Ic5a1dbd098d251588ff528cf2a63f2189cb783af

This will help the QA team and make it easier to quickly see what is in a build.

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

Change-Id: I0597436bddcd79f7a44d3969b54a3ae2e02b3c70

just to build it, needs a bit of love for runtime cases I suppose

Change-Id: I9f5d4e4012e0addc8173f126fc93a2ec3eb9de45

Change-Id: Iaa142d5d0ac0f00e89e8b7d7ffdef8137157cec9

using same way as gradients, bitmap, etc.

Change-Id: I49788d5af163aa6f06a12c87ee08e6599fc940c8
Reviewed-on: https://gerrit.libreoffice.org/31833Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

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

MultiLineEdit is a special control which can have
more text portions with different text attributes.

Change-Id: Iab51dba0d0344fad4358f4961c968c031b1660b6
Reviewed-on: https://gerrit.libreoffice.org/31813Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>

Change-Id: Ifc143f33bc4e087726ada1e3b1b5182bf830b0cb
Reviewed-on: https://gerrit.libreoffice.org/31821Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

so have the same hidpi solution on both setups

Change-Id: I669eba55830a28c1850f4679dfa824798bd3a383
Reviewed-on: https://gerrit.libreoffice.org/31540Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

Change-Id: I5e3480b647ec3851e9125188d9cd04227050dc6d
Reviewed-on: https://gerrit.libreoffice.org/31817Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
Tested-by: Khaled Hosny <khaledhosny@eglug.org>

Also simplify code to what is actually being used.

Change-Id: Ic640ea7f3e426e3f5f4f9fef30d774fe5ac111ff
Reviewed-on: https://gerrit.libreoffice.org/31815Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

Change-Id: Ic0dd8c0311161271817eb9a3f454d00a319e43a8
Reviewed-on: https://gerrit.libreoffice.org/31814Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

We have this nice structure that contains (almost) all the information
we need, so pass it around instead of passing separate fragments of said
information.

The ultimate is to kill the horrible sal_GlyphId hack if encoding
various bits of information in the higher bits of a 32-bit integer.

Change-Id: Ie496bb4c2932157527a388e2a94e46bf0a325a70
Reviewed-on: https://gerrit.libreoffice.org/31781Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

Change-Id: Idc50ef5eb250a2a68ae6c6aaed969289baaf38f4

ToolbarLayoutManager::createToolbar() may be called concurrently on
different threads, and then it can happen that both threads want to
create the same toolbar URL, see that it does not exist in line 457,
then both release the SolarMutex and create a new ToolBarManager
and the first inserts it and then the second overwrites it on line 514
without disposing the first one.

The non-disposed extra ToolBarManager is kept alive because it is
registered as a listener on the Frame.  When the Frame::close() is
called, the ToolbarLayoutManager is disposed, and that disposes all the
ToolBarManagers it knows about, but not the extra one, which is
then un-ref'd and then has a live VclPtr m_pToolBar, which asserts
because the SolarMutex is not locked since commit
e794ce1e.

(This commit is thanks to rr, which recorded the
JunitTest_framework_complex execution and allowed debugging this.)

Change-Id: I8f5333e8e36ac8ea347ef545e014ffc10501aebb

Change-Id: Iecb64ab1e25913180bcb53a133f9dd6777ffb17b

SvXMLAutoStylePoolP_Impl re-starts with a clean
XMLAutoStyleFamily::maReservedNameSet, so reserving the names in
ScXMLExport::ExportStyles_() is not enough and needs to be redone in
ScXMLExport::ExportAutoStyles_()

In the bug scenario that lead to cell styles with duplicated names for
different styles of which when reloading only the first was taken.

Additionally, a style must be registered after SvXMLAutoStylePoolP::AddNamed()
to prevent duplicated styles with different names.

Change-Id: If3491eb89ab1741887d9a36ecf904a216fb1368e

For markers (resize markers, anchors,...) we contain them all in
one image atlas. This was generally done because of resource
limitiations in Windows 95/98 which aren't a problem anymore in
present systems.

This is however problematic in HiDPI as we scale the image and
the coordinates of aren't correct anymore. Another problem is
that it uses its own cache instead of common cache in
ImplImageTree. So this commit extracts all the markers into its
own images for galaxy theme and uses them when we scale.

In the future when we extracted all the markers to its own
images for all icon themes we can remvoe the old code with the
image atlas.

Change-Id: Ibee181b529d30e20050df8cd396d338bd53532c0

Change-Id: I201055f6fede41144e308d53d2cbd24afced86ae

Change-Id: I5a721b2b55c003c34e24d83b9b5e09a88dde684b

Change-Id: I840b28f419137d2ead44dc649a14d742055fb3b9

Change-Id: I4e52851b41e3d5ec4fe4ae5277928bceac3c8283

Change-Id: I8bc95282b709dcf47469b09326d434297976b6d0

Change-Id: I5330b681d540a42a655a10abf8b533a74d8687f6

Change-Id: Ieb58ed113c6a3e85a806ec57a6557e2d37bf9b06

Change-Id: I9aa8c807714f32ba5896a9308f36fcc8ab462a3d
Reviewed-on: https://gerrit.libreoffice.org/31749Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jaskaran singh <jvsg1303@gmail.com>

Change-Id: I2a4efc9ade69ab53da81c72528e18ecb99e99757

Change-Id: I7bdd15a93e728ef7e98a53001c6eb6b56f761a6d

...that go unnoticed due to the non-explicit VclPtr::oeprator reference_type *

Change-Id: Ia63edf8425d3ecb7c7f98eb56a710ac0cceccb67

Since commit ac6bfd85 (tdf#92045 DOCX
import: <w:effect w:val="none"/> doesn't mean blinking, 2016-01-06) the
"no blink" blink type is not 0, but
NS_ooxml::LN_Value_ST_TextEffect_none.

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

this seems to be a problem since....

commit 199eb08b
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date:   Thu Jun 5 16:25:01 2014 +0200

    SwAnchoredDrawObject::GetObjBoundRect: avoid SwDoc::SetModified()

    This is a const method, but it does a const_cast to still resize an
    object... if that's so, then we should ensure that the "is modified"
    flag of SwDoc is untouched.

    CppunitTest_sw_ooxmlimport's testChartSize is a reproducer for this,
    when shape text is imported as textbox.

(note under gtk3 and wayland this isn't as noticable, there use
export GDK_BACKEND=x11 to reproduce the freeze effect where even
the mouse cursor doesn't move during part of the load)

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

Change-Id: Ie42b2e173cd3ed9faaf17c3c978227613129fa84

Change-Id: Ifacff75f80bc8401ccff2a4d4dc90e56e3b4aa84
Reviewed-on: https://gerrit.libreoffice.org/31801Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>

the bug here was that we had, on the stack, going into the scheduler
THREE times. Two of those were idles.

The original code would end up always picking the first idle from inside
    ImplSchedulerData::GetMostImportantTask
and then
    ImplSchedulerData::Invoke
would just return because we were still inside that Idle, and the second
Idle would never get executed

Since the second Idle was responsible for painting the dialog in the
bug, sometimes the dialog would never get painted.

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

because if the opengl support is such that the opengl-for-vcl requirements don't
fit, then on the second run after discovering this (the first having restarted)
if you try opengl slide transitions libreoffice will just exit because it
thinks this first check of opengl-for-slideshow is the first opengl-for-vcl effort.

so move this code into the place which I believe is the opengl-for-vcl entry point

this is all related to...

commit 210c39dd
Date:   Fri Jun 3 09:25:13 2016 +0300

    tdf#100193: Check earlier and harder whether OpenGL is good enough on Windows

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