Change-Id: Ida1351dda42f2dc0ddb50dbcbd55564d64280c15
Reviewed-on: https://gerrit.libreoffice.org/71655
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

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

Under gtk 3.24.8 dragging into the TreeView is not highlighting the entire
rreeView widget, just the rectangle which has no entries in it. This looks ok
when its empty, but not when it has some entries in it, and when the list is
full, there is then no border highlight.

So as a workaround highlight the parent container on drag start, and undo it on
drag end, and trigger removal of the treeview's highlight effort.

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

Similar to clang-tidy readability-container-size-empty

Change-Id: I71e7af4ac3043d8d40922e99f8a4798f0993294c
Reviewed-on: https://gerrit.libreoffice.org/71603
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

(lexicographically, by Unicode code point values; to make it easier to add
further entries)

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

...by storing the temporary HTML document in a location that can be accessed by
the browser running outside the Flatpak sandbox.  This reuses and extends the
mechanism already in place for the new HTML-based help in Flatpak mode (see
72b936d7 "Enable --help=html for flatpak").

This fixes <https://github.com/flathub/org.libreoffice.LibreOffice/issues/85>
"“Preview in Web Browser” does not work in Flatpak version".

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

Localized range separators resulted broken XLSX export
with duplicated built-in names. For example, XLSX export
of a Format->Print range using Hungarian locale in LibO
raised an error message in MSO, because the export
contained the same range also with a bad semicolon:

<definedName>Sheet1!$A:$A;Sheet1!$1:$1</definedName>
<definedName>Sheet1!$A:$A,Sheet1!$1:$1</definedName>

Change-Id: Iee6ff7c5f5952fc1e736cebfc290c64a851786ab
Reviewed-on: https://gerrit.libreoffice.org/71538
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>

Move XReplaceDescriptor Java tests to C++ for ScCellSearchObj.

Change-Id: Ica5042ce8b5eac3663a0fb5f66ae0a2830c89d93
Reviewed-on: https://gerrit.libreoffice.org/71645
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Move SearchDescriptor Java tests to C++ for ScCellSearchObj.

Change-Id: I3c9ffbfc80c7fdc39d0e67fe8aae12605a8d04f5
Reviewed-on: https://gerrit.libreoffice.org/71644
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Move XSearchDescriptor Java tests to C++ for ScCellSearchObj.

Change-Id: I1ae50bb586fd742b7cc19f71bcae018ca42139e6
Reviewed-on: https://gerrit.libreoffice.org/71643
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

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

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

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

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

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

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

Change-Id: Id8f78e2b114945f2c2499739711db9223828314a
Reviewed-on: https://gerrit.libreoffice.org/71609
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

The reasoning is somewhat complex:

void Window::ImplInvalidateFrameRegion( const vcl::Region* pRegion, InvalidateFlags nFlags )

sets the mnPaintFlags on the mpWindowImpl - and then queues an idle
paint. This paint in LOK mode does ~nothing - since all rendering is
tiled, although amazingly it does emit eg. selection callbacks.

However the paint flag - changes the behavior of Window::Update() to
force a complete window invalidate. This happens, but only rarely -
when a key-event manages to get into the mainloop before the idle
paint handler arrives and does nothing (except clear the paint flags).

So - don't do these big invalidations we don't need to in lok mode,
unless it is for dialogs - which presumably Pranav wanted fixed by
625087b5.

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

Change-Id: I6d204a7ba0fa19f4c318d1c70f5a0344e0640d6d
Reviewed-on: https://gerrit.libreoffice.org/71620
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: Ia35e3bb3b4f0323c7fbfc54ae5064afdf2c3f381
Reviewed-on: https://gerrit.libreoffice.org/71539
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I16149cabf75ec928d96975e4b98622df6951cefc
Reviewed-on: https://gerrit.libreoffice.org/71519
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

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

Previously, for an XML like this:

    <sharedItems>
        <d v="2017-07-10T09:11:02"/>
        <d v="2017-07-10T09:11:03"/>
        <m/>
    </sharedItems>

the call like

    int pos = getXPathPosition(pDoc, "/x:sharedItems", "absent");

gave 3. That could result in mistakes, when a test would assert
on position "3" for a child element which name is mistyped.

I made such a mistake when creating a unit test trying to assert on
a position of the last element, and writing its name as "x:m", like
in rXPath itself; the return was 3, and I initially wrongly assumed
that the return is 1-based (like in xpath bracketed expressions).

rChildName made const OString&, for consistency with rXPath, or with
rAttribute in getXPath: child name is just a part of a longer xpath.

Change-Id: I7ba9c4466c75b1b10fce1ccf26ef3b56b4e11e87
Reviewed-on: https://gerrit.libreoffice.org/71614
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Change-Id: I90e103f1ded9671817b83ae4755c235acf4050f1
Reviewed-on: https://gerrit.libreoffice.org/71619
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: Id3f8a0e7b03e47d5f09e87320006fbed293e941f
Reviewed-on: https://gerrit.libreoffice.org/71602
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

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

... so that 2017-07-10T09:11:02.999999... becomes 2017-07-10T09:11:03,
not 2017-07-10T09:11:02. The latter created duplicated items in pivot
table cache previously.

TODO: check what to do if the times are actually different by 100 ns?
What Excel does then? Should we increase cache item precision?

Change-Id: I622d1c784ee9fddf6b387bec2d8af87bae5668ba
Reviewed-on: https://gerrit.libreoffice.org/71610
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Move XPropertSet Java tests to C++ for ScCellSearchObj.

Change-Id: I46e55794fe0b205173c3b208ba84c90d70aa2de0
Reviewed-on: https://gerrit.libreoffice.org/71608
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

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

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

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

Just because this image is transparent, does not mean it is equal to the
other image.

Similarly, just because this image has transparency color, does not mean
the other image has valid transparency color.

Also move the cheaper mbAlpha check before the more expensive
ShallowEquals check.

there since
    commit 8ab086b6
    Date:   Mon Sep 18 16:07:07 2000 +0000
    initial import

Change-Id: I63033bc8e7fed991513a171e637768e826eafad9
Reviewed-on: https://gerrit.libreoffice.org/71572
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I4934240946b435e7b5b13c2623143f7741106efa
Reviewed-on: https://gerrit.libreoffice.org/71599
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I595c8494bef7c9dae16ae17bd963c79097f4a4c6
Reviewed-on: https://gerrit.libreoffice.org/71607Reviewed-by: andreas_kainz <kainz.a@gmail.com>
Tested-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: I12c8f7d73f9047e570fa094da82429fa3f523841
Reviewed-on: https://gerrit.libreoffice.org/71605Reviewed-by: andreas_kainz <kainz.a@gmail.com>
Tested-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: I7614637d8b793d7e5329e110448dbdb04ada273d
Reviewed-on: https://gerrit.libreoffice.org/71606Reviewed-by: andreas_kainz <kainz.a@gmail.com>
Tested-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: Iaa20611ccde1d53cd85db63cbdab450c1622a303
Reviewed-on: https://gerrit.libreoffice.org/71601Reviewed-by: andreas_kainz <kainz.a@gmail.com>
Tested-by: andreas_kainz <kainz.a@gmail.com>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: Id0b9a5816ee459837ca8fe2b4dd7a0233a517c0d
Reviewed-on: https://gerrit.libreoffice.org/71604Reviewed-by: andreas_kainz <kainz.a@gmail.com>
Tested-by: andreas_kainz <kainz.a@gmail.com>

Reduced svg size

Change-Id: Iccfe353d33f7c78600a1cdf24fd67038831fc692
Reviewed-on: https://gerrit.libreoffice.org/71562
Tested-by: Jenkins
Reviewed-by: Matthias Freund <matti_lx@secure.mailbox.org>

Commit a51b7a1c (tdf#103831, tdf#100986:
Force using GDI when needed, 2017-03-03) noted that the DirectWrite text
renderer doesn't support vertical text, add initial support for this now
by extending the DirectWrite transform matrix to do rotation as well.

This is initial support, as it can be improved in two ways:

- vertical text is not cached

- only vertical Latin text is handled, which wants rotated glyphs (vs
  e.g. Japanese text that would not rotate the glyphs)

With this, the "unreadable" text in the bugdoc's chart is on par with
the the GDI rendering.

Change-Id: I07af4de6cb437f83cc40546396ec8c8aac456bb3
Reviewed-on: https://gerrit.libreoffice.org/71592Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins