The calc macro test tries to select a range of cells by moving selection
right, but this fails when the UI direction is right-to-left as the
first cell will be the right most and moving right will do nothing.

Fix this by forcing en-US locale like we do with JunitTest.

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

Project: help  84c9ad7e308a3fa3809529aac4557c0b4cde823e

Sort bookmarks alphabetically in HC3

Change-Id: Id26048f7ebfdccc2e5afd8a851a0f30c7a78fda0
Reviewed-on: https://gerrit.libreoffice.org/32249Reviewed-by: Olivier Hallot <olivier.hallot@edx.srv.br>
Tested-by: Olivier Hallot <olivier.hallot@edx.srv.br>

which is responsible for aliasnames defined with the SQL 'AS' keyword.

Change-Id: I6aaf1ba6969e2bd738941e41492338382168bc89
Reviewed-on: https://gerrit.libreoffice.org/32042Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: I04a2181b05f2b15a55db306f49b47855db7753db
Reviewed-on: https://gerrit.libreoffice.org/32204Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Tested-by: Jan-Marek Glogowski <glogow@fbihome.de>

Change-Id: Id03606deaf207f579ee3c56437b37f4981538d12

...at least macOS doesn't like that; change from OSL_TRACE (effectively doing
nothing unless running a debug build with SAL_LOG=+INFO) to SAL_INFO (calling
std::stringstream -> malloc in debug builds, regardless of SAL_LOG env var) in
a005fbed "OSL_TRACE->SAL in framework..sal" made
the mistake obvious.

Change-Id: I43d35524a0861998a1ef58c6f448085a2fb01cd5

Change-Id: I6b97345c9d927d1ae1d89f85611c2b5de7b5f0d4

Change-Id: I7d9ca3812b1af35e6155ff269ee88cf4101de14b

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

which isn't available on a static-only build (iOS and fuzzing) and
android

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

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

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

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

Change-Id: Id918ae46ed521fca5675845b2eb9cd26a8c7ebbb

ComboBox just uses ListBox internally

Change-Id: Ieed279160db1c9918bd9f3e37102b59ea62f0581

Was found and marked in 03f440c3,
but is definitly wrong.

Change-Id: I6d04814fb8f25a92dfaf96d8face855315cc0208

Change-Id: Id392b7c42d6470230a4d9f627704286e532dce3e

Change-Id: I4fffd086a38b54c673a199ea0603d25ca54aacd1

Change-Id: I03fa5489ffc5cd5bb386bb321519c61058db4fda

Change-Id: I7a1e89c0c058bab0b6665e2b96b22251dcb51f4f

Removes the old, copied NWS documentation blocks from all native
implementations and update the parent SalGraphics documentation.

Change-Id: I0eff8ea0987c5c841e1b023340b1c3787c09e2ca

Instead of guessing, use the CalcMinimumSize(), which also knows
about theming.

Change-Id: I747571b48c81166d11d03f99ab564b1a25165ef3

At least not needed with breeze KDE4 theme.

Change-Id: I71a05c395d04a6f19c3bcd681450318831b0c29f

... and don't claim to support all parts per default.

Change-Id: I7a8e0774b4573bf755737bc1adebe19a774736c9

When recalculating the native window frame borders, calculate
using already existing window borders. Otherwise the KDE edit
box results in an unlimited recursion for increasing the
bounding rects, if the control doesn't fit.

Change-Id: I45e51e4796b06097ca537c656f004133dfacd033

These are used to paint Writers ruler text and marks.
Makes both readable with disabled and inactive text colors.

Change-Id: I39766d623164230a7379623c16e0463cbaaf0af8

Change-Id: Icce8bc0c1031ad0d1b53fa7389e1a75f16e62972

Change-Id: I3d6a1696b8278066b005c1983d226cc67381ba95

Just rely on the default window backround.

Change-Id: I8aa7a2b05ac2521b872290d508c0ce5fdaf83bae

The custom shape popup toolbars used their own drawing code for
the drag handle. This was dropped in favour of the default toolbox
drag handle code.

This also drops the drag highlighting in favour of a move mouse
cursor as the drag indicator. The drag handle is currently always
drawn on the top, like a window title.

Change-Id: I08cbf715f1e240c2eb6d9a61fad2b705f9bd8014

This just move the declaration from the shared header to the
corresponding cpp files to make them static.

Change-Id: I4aed6e23a90d42114d815205db2b741080739ac1

Change-Id: I405160743609aae92a37b2359bea5aa42ee66519

Change-Id: I2fff46985502dafa3b860aaebe862853ebaccabb

It seems unused in the first place.

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

Interesting parts of the bugdoc:

- it has a numbering definition with two levels
- first level's type is none
- second level has a numbering string: "\x01."

Usually these placeholder bytes in the numbering string start from 0x00,
but there it starts at 0x01, which means the layout has to replace it
with the numbering from the second level.

Mapping from the spec to the code:

- nLevelB is an index into rgbxchNums
- aOfsNumsXCH is rgbxchNums
- sNumString is xst

So when the rNotReallyThere added in commit
251ba90d (INTEGRATION: CWS
soberfilterteam06 (1.44.26); FILE MERGED, 2003-05-19) wants to clear out
indexes from aOfsNumsXCH, it talks about numbering levels. The old code
assumed that nLevelB is the same as nPosValue, which is true in many
cases (when the levels are like 1, 1.1, 1.1.1), but not in this
particular case, where nLevelB is 0, but nPosValue is 1.

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

Change-Id: I1b94438e43df6f1f8f7774d9e86f415785e60284

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

Change-Id: I58c37a68c8695b68296f0eb652e3075ea1528108

Change-Id: Icbecfd287174e5d7be9bbf7dc235d1966a6858ff

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