There's pretty much the same code in CanvasHelper::fillTexturedPolyPolygon()
that has received various fixes over the time, but this code not, so
fix it as well.

Change-Id: I7293d4d67dff2d5276928bb3ab25adfb883ce3ca
Reviewed-on: https://gerrit.libreoffice.org/72700
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

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

See <https://gerrit.libreoffice.org/#/c/67754/3> for discussion, the
stability of this test has to be improved before it can be enabled
again.

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

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

The problem here is that we never actually hit the maExportGraphics
cache in SvXMLGraphicHelper, even though we are passing the same image
down repeatedly.

There are two bugs here:

(1) BitmapEx::operator== does not return true if we instantiate 2
Graphic objects from the same XGraphic, so change it to use the more
expensive operator==. To mitigate the cost, move the expensive checks to
the bottom of the method.

(2) in order to use an object in std::unordered_map, the object must
implement an equality function and a hash function. If two objects are
equal THEY MUST have the same hash value. Using the Impl* as the hash
value does not satisfy that condition, so rather use the checksum, which
does.

After these fixes, the save time drops to less than a second.

Also make the checksum method look more like the operator== method,
and add a checksum calculation method for SVG data that more accurately
reflects the underlying SVG data.

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

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

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

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

by considering the axis direction.

Note: Legend name order in left/right position was fixed in
commit 40144617

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

and endnotes by creating redline data for their anchors, too.

Now footnote/endnote insertions are visible, and it's possible
to reject them.

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

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

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

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

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

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

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

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

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

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

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

The problem with latest macOS versions is that creating a graphic
context with window (NSGraphicsContext graphicsContextWithWindow:)
only works when actually drawing and otherwise it returns null.
This caused problems before in AquaVrtualDevice, but we also use
this when creating a device backing storage. This interestingly
caused slowdowns and eventual crash, but the backtrace looked
very misterious as it didn't crash because of a nullptr, but
it halted all drawing commands and it crashed because of that.

This changes the graphic context with a bitmap context, as it
was already done in VirtualDevice and use that instead. The
problem with a bitmap context is that we need to handle HiDPI
scaling by ourselves now.

LayerHolder was extended to store the scaling information of the
layer (and its underlaying bitmap context) and provides methods
that get the size of the layer in pixels or in scaling independent
points (which is just size in pixels multiplied by the scaling
factor).

An known issue is that VirtualDevice also needs to take scaling
into account, which it currently doesn't, so the text is still
blurry on a HiDPI screen, but that was already true previously
and is something that will be done in a different change.

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

This adds the ability to define the spinbox orientation that has
decrease and increase buttons on the right side and can be changed
by adding "orientation="edit-decrease-increase" to the Spinbox
"Entire" part in the widget definition.

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

This is similar to e8d5b8be (tdf#113714
vcl menu bar window: avoid flicker, 2019-05-20), except that was for the
menu bar window, and this is for the floating window opening from that
one.

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

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

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

Since the guard is only cleared optionally, most probably the code after
the conditional block is expected to be guarded until the second clear.

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

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

Revert the commit caused this regression:
0fc41c53

The original issue does not come back with
reverting this commit.

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

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

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

by sending the notifications to the parent windows as well

Change-Id: Ibb33f608d7b9c3871aadd0c13db32effd99fe698
Reviewed-on: https://gerrit.libreoffice.org/72675Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

A threadpool controls a number of threads that execute a number
of thread *tasks* from a queue. The API even says they are tasks.
So it's damn confusing when ZipPackageStream::saveChild()
claims to limit the number of threads to 4x the maximum number
of threads. It limits the number of queued thread tasks.

Change-Id: I317497f27a82d92a7c8566b14aaeae73a4ffef1f
Reviewed-on: https://gerrit.libreoffice.org/72677
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

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

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

Windows (by default) and gtk3 paints its own background, but e.g. the
Linux gen backend does not; so make sure that we not only copy from the
buffer, but also initialize it.

This restores the gradient background of the main menu with the Linux
gen backend.

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

Change-Id: I4036061b9e8f01d99f04f20dfbbd2cf23d3a9b59
Reviewed-on: https://gerrit.libreoffice.org/72632Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins

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

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

Restored java 6 compatibility

Change-Id: I550920457874b9261bdde07040aad8f7b67773d8
Reviewed-on: https://gerrit.libreoffice.org/72671Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

1) after many trials and errors what LibO apparently expects here is
the ID of QWindow parent of [embedded] system child window

2) the position of the embedded window for video overlay has already
been translated relative to the top-left corner of the slide (see
bugfix of tdf#42873 how) in gen, gtk and kde5 vclplugs. So let's limit
translating it 2nd time only to gtk3 vclplug which for some reason
behaves differently 
(regression from 18138417)

Change-Id: Ie4c6d14a50959c0fdd04e745918d4889c9da45ec
Reviewed-on: https://gerrit.libreoffice.org/72458
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

At least building on Flathub makes presence of this information a hard
requirement now (see <https://blogs.gnome.org/hughsie/2019/03/28/
new-appstream-validation-requirements/> and witness the failed
<https://flathub.org/builds/#/builders/32/builds/3597>).

The suggested way to calculate that information is via the form at
<https://hughsie.github.io/oars/generate.html>, which I filled in as follows
(the answers I selected are prefixed with "=>"):

> By answering all the questions you can generate AppStream-compatible markup
> for the upstream AppData file.
>
> If the user is able to "enable" NSFW or "adult" content, then this should be
> included in the assessment even if it is turned off by default.
>
> What type of component are you generating content for:

=> Application that can connect to the Internet

> OARS has multiple versions, and the newer versions include more questions
> involving specific cultural and religious sensitivities. What version of OARS
> metadata do you want to produce:

=> 1.0 (works with all clients)

> Advertising
>
> Defined as the activity of producing advertisements for commercial products or
> services.
>
> For example, this would include banners showing the Coca-Cola logo shown in a
> Soccer game.

=> None

> Gambling
>
> Defined as taking a risky action in the hope of a desired result.
>
> For example, this would include spinning a wheel to get in-app credits.

=> None

> In-App Purchases
>
> Defined as items or points that a user can buy for use within a virtual world
> to improve a character or enhance the playing experience.

=> None

> Online Text-only Messaging
>
> Defined as any messaging system connected to the Internet.

=> None

> Online Audio and Video Messaging
>
> Defined as any multimedia messaging system connected to the Internet.

=> None

> Contact Details
>
> Defined as sharing identifiable details with other users to allow out-of-band
> communication.

=> None

> Information Sharing
>
> Defined as sharing information with a legal entity typically used for
> advertising or for sending back diagnostic data.
>
> For example, this would include sending your purchasing history to Amazon.

=> None

> Location Sharing
>
> Defined as sharing your physical real-time location.
>
> For example, this would include uploading the GPS co-ordinates of your current
> location. NOTE: This does not include heuristic based location services, e.g.
> GeoIP and others.

=> None

> The following markup can be pasted into the existing application AppData file.
>
> <content_rating type="oars-1.0" />

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