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

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

found while changing base of SvxFrameDirectionItem to SfxEnumItem

> warning: comparison between ‘enum SvxFrameDirection’
> and ‘enum com::sun::star::text::WritingMode’ [-Wenum-compare]

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

Could have sworn I did this originally, somehow it got lost.
Also fix a thinko in tools::ResId I introduced in commit
2b70fb58
"Use o3tl::strong_int on RESOURCE_TYPE"

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

Change-Id: I5c7d1d47f347b3ce8de6e2e4995da8724a464941
Reviewed-on: https://gerrit.libreoffice.org/35045Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>

to skip a push to the stack immediately followed by a pop.

Change-Id: I97eb48db2521d640acec4d8080cceb56561eb901
Reviewed-on: https://gerrit.libreoffice.org/35129Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
Tested-by: Takeshi Abe <tabe@fixedpoint.jp>

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

Change-Id: I6ec50033a452493852729dc8efe78da2708cbd96

Change-Id: Ibe41e1edb717b4e740971f4b972abdea769460eb

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

adds an extra SVSTREAM_WRITE_ERROR check to some of them, otherwise
they're all the same

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

Change-Id: I5f3e1a8fe559500aec7ea9e38edaba42dff3f98b
Reviewed-on: https://gerrit.libreoffice.org/35028Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: Ia89f068d93b810b0c32df5df62a582322f3e5588
Reviewed-on: https://gerrit.libreoffice.org/35142Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

No point in outputting the enum class name when we know it is a value
from that enum that we are outputting.

Fix some random whitespace craziness.

No point in putting that symbolic representation of an enumeration in
double-quotes. It is not a string in any sense.

We can pass an OUString directly in SAL_INFO.

Be consistent, put a double-quote on both sides of the string (font
family name), if at all.

This is a way too verbose commit message for such a trivial change.

Change-Id: I9e3f96856a634dc16f0e24f789c1898d7ec75fd9

Fix C4806: '&': unsafe operation: no value of type 'bool' promoted to
type 'int' can equal the given constant

Change-Id: Iedd54379a67373fb3499a0a780f2cbfc83f08e84

Change-Id: I376933a033a2dc2b5b7b59006b93d14a65463aed

Change-Id: I6b9423db247583ff1dcbd469db5dfab7f89e7457

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

...and get member function const'ness right overall

Change-Id: Idb422039108d1dde9f6a8b881f6dff742030f6f0

Change-Id: Ide32700aab3427a8bf18c806968822cdf3f91bf2

Change-Id: Ia315f446c374ac08d8a4b7247c571b70cbbab5ae

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

Change-Id: I81a59c7847e2109198a35cbdb49f5bcf3505c4ba

Change-Id: I3afb31b642a47e767dda0614d223b6b7f22e5d54

Change-Id: If728a1da99d9146d60d15b5273a7a89764b82d51

I guess you can only see the problem if you not only do a from-scratch
build (like Jenkins does) but also empty the tarball cache.

Change-Id: I1238e35abe1a6009ce0e0c3406e20aa1879c65bc

if we are a hairline along the very right/bottom edge
of the canvas then distory the polygon inwards one pixel right/bottom so that
the hairline falls inside the paintable area and becomes visible

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

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

... so only SvNumberFormatter can use it, as intended.

Change-Id: I91875dfd00d1f83b3ae988bda922782336489f73

(user-provided virtual dtor in class with dependent base)

Change-Id: I37b3cc3d32e76a0286ecc91f999920e3dfe706cc

(vs. uses of sal_uInt16 representing such items' IDs).  APPEND and ITEM_NOTFOUND
are members of ToolBox now (and have been bumped to the corresponding type's
max).  The payload of VclEventIds

  ToolboxButtonStateChanged
  ToolboxClick
  ToolboxHighlightOff
  ToolboxItemAdded
  ToolboxItemDisabled
  ToolboxItemEnabled
  ToolboxItemRemoved
  ToolboxItemTextChanged
  ToolboxItemUpdated
  ToolboxItemWindowChanged
  ToolboxSelect

has been changed too (note that reading/writing of those payloads isn't very
consistent, though: for some of these, values are written that are never read,
while for some others no values are ever written but the reading code would like
to receive some value if the payload wasn't a nullptr).

Change-Id: I4856ffb3637404b8d866621a3503d7922b1b8141

Is suspect something has changed in gtk3, and I think we're
not supposed to use gdk_drag_drop_succeeded at this point, but
instead we'd get a dragFailed signal on the failure case

Change-Id: I6b305db56a29255b468ca9182d1f7e57cb4c10f4

...not positions in the [0..GetItemCount()) range, so what's probably missing
here is to map from positions to IDs.  Code was originally introduced with
8a429819 "findbar01: enhancements for findbar".

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

...not positions in the [0..GetItemCount()) range, so what's probably missing
here is to map from positions to IDs.  Code was introduced with
f25cdaa7 "fdo#74132: Do not interrupt search in
Writer."

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

MSWord normally does NOT specify "nextPage" for the sectionBreak,
since that is the default type. That is imported as BreakType == -1.
However, Writer ALWAYS exports the section type name, which of
course is imported explicitly.
**There is an import hack that treats the very first -1 section as
continuous IF there are columns**. Since Writer explicitly defines
the section type, these documents import differently.

When Writer round-trips these types of files, they get totally
messed up in Writer, although they look fine in Word. So, treat
both implicit and explicit nextPage identically for
bTreatAsContinuous during import.

Another unit test demonstrated that headers/footers are lost when
treating as continuous, so preventing that situation now also.

This fix allows several import-only unit tests to round-trip.

Change-Id: I37fa861d82e8da564d28d8e9089fe0f2777650fb
Reviewed-on: https://gerrit.libreoffice.org/35013Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

As it causes "unopkg.bin:
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/comphelper/source/misc/threadpool.cxx:96:
comphelper::ThreadPool::~ThreadPool(): Assertion `mbTerminate' failed."
in
<https://ci.libreoffice.org/job/lo_gerrit/8283/Config=linux_clang_dbgutil_64/console>
and also locally. Revert till it's clear if that assert() should be a
SAL_WARN() or unopkg has to be fixed.

This reverts commit 9899ffd2.

Change-Id: I72902f7da410012340aa8231d84c6871a3f7b976

Change-Id: If96fbf097e2314303e60fd4f10ae314d12f2c468

Change-Id: I960768ff98137a50da44348bffeec329295ea95f

Change-Id: I7acdea720ba29eb9b9fb3ef8e8cbc76a673d17c2

Change-Id: Iaf6310055b60da772187fdbeaca74d6eb296cfca