Change-Id: I589f49179b446ae24037546075070641de5cb927

Change-Id: I13252ac17fd4fca96992bf48c8dbdebd01c479dc

Change-Id: I3c733ac46b89b0a6b413eadf2796b80ec033c2c9

Change-Id: Ib2812723141c5dfe39b30c95f12d1aeca9c367bd

Change-Id: I41f3fa14ee06339685b608d1081466d4622999da

Change-Id: I4ebecb2bda44319a3590a62a2c113c73c94ba974

Change-Id: If4c3265f76987d9f59388d3c12441ccb2b03a308

Change-Id: I3f3797d323ea6f438d4fdcb7f89c28b658e75b57

Redrawing is done in-place at some places and not in Paint()
chain. This was refactored to delegate such places to
invalidateX method, so it can be changed later.
Refactored some static functions to methods, when that made sense.

Change-Id: Ibdf4211857f4911b48b61edd2ecc846a6e94c864

in my commit b35828ba
"convert CONFIG_MODE constants to scoped enum"

Change-Id: Iafb6b1643920eb066a2d50150f408161331f9d04

Change-Id: I9cd8474c658643d1f6044ecf6c56efdd42530979

include/o3tl/typed_flags_set.hxx: In instantiation of 'o3tl::is_typed_flags<ImplFontAttrs, -0x00000000000000001>':
include/unotools/fontcfg.hxx:88:94:   instantiated from here
include/o3tl/typed_flags_set.hxx:66:5: error: static assertion failed: "is_typed_flags expects only non-negative bit values"

Change-Id: Ica7873bef3fd664370a96d8066d63c473ff6798f

Change-Id: I1697f563d21c02551088ea1469eb973a6cfc5a10

Change-Id: I6933393732d23fe9386cb8b768676887c026bd39

Change-Id: I205f7348993031e0dd72c74531ca67e3e87e809c

Change-Id: Iac3c8d30acff0984a98a4b705957c0361a5ead2f

The underlining of accelerator keys creates a visual conflict with the
descender strokes of the letters g, j, p, q, and y, which slows down
visual scanning; not to mention that some UI fonts might be especially
problematic due to their design (I’m looking at you, Apple, for choosing
the grotesque Helvetica Neue, which is particularly unsuitable for UIs).

Spotted by Clara Ginovart Cid.

Change-Id: Ia559904b2f2fc1eddbea0193e95c929f7650c6f0

Change-Id: Ie360ae76f8692abbc5487f9b76b543477cce438b

Change-Id: Ib08482d0a3f6cb62e16a21fba2025913ca1aedad

Change-Id: I0a299050d8ae19bdac555e75116c5b85f409a6c2

Change-Id: I0efce31e0f7cc5aa4895b6e5e35432d3f0c6fb70

Change-Id: Id268393bf28a6edb4a481d7a74ae412b337b3fc8

Change-Id: I34cdae7182631ca2d6e86f94f244e9362fe9dc6b

Change-Id: Ib045828769bece2a6524d2d84b6e8ee23d305e28

Change-Id: I0549a58bc6cebdfd9d69c078b4a6e8a891182019

So do the verbose OUString::number().toUtf8().getStr() dance.

Change-Id: Ied5f6c3ec936544f0f36eeafd07f9496e9061373

Continue https://gerrit.libreoffice.org/15606/
5a8c7fd551522bdfe935f4138bde0df376464608

Rebase of https://gerrit.libreoffice.org/15233/
Update with more robust tests.
Update create NumberFormatPropertyPanel.[hs]rc

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

Hoping to fix the Android compilation.

Change-Id: Ibb476edebc6b2da040af8c8db04efa39882c5bf0

Change-Id: I16cbc7d772f39c8778b8ba21a629ced6b0dbedeb

Change-Id: I70d3f595b3fe26b77788a668a430d4d777320754

Only found the exception with the Debugger, when exit the swriter.
The appliction stop the SalTimer, but the own message
(SAL_MSG_TIMER_CALLBACK) is in the message-queue and restart the
timer again. After that, the SalData would be delete and then in
SalTimerProc use the SalData, then exception.

Change-Id: I8e02a38d4e741cfd31de605cb5b172b28a0909fb
Reviewed-on: https://gerrit.libreoffice.org/15649Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

This adds ScDocument& to all RefUpdate...Context; another approach could
had been to add an UpdatedDBData similar to UpdatedRangeNames and gather
those in the ScDBData::Update...() methods, but as long as
ScDBData::IsModified() works that isn't necessary.

Change-Id: Iae3ec6c8b8356cbd8acb2445489e91e7d6922fb3

Change-Id: I636453e8cab09ec5021acd2bb1f2937f1402dccc

The libsofficeapp and LibreOfficeKit API bits.

Change-Id: I4efe9880dfa4e0387f05b50e64b5eaee448e0925

It can well be that the StatusIndicator code is called for multiple
independent sections while loading some document format, and that the first
progress is not the one that actually takes much time at all, so following
just the progress of that would be misleading, the progress would be "stuck"
at the highest value set by the first progress (forever, if it has gone up to
100%).

For example, when loading the odk/examples/java/DocumentHandling/
test/test1.odt sample document, the code first calls the StatusIndicator while
parsing the styles.xml, going from 0% to 100%. But the styles.xml is typically
rather small. Then the code calls the StatusIndicator *again* while parsing
the much more relevant concent.xml. For that particular document, this time
the progress goes from 0% to 27% only, for some reason. Oh well, GIGO.

Change-Id: I87bfc586a53efcbeb94924f21dd365ca63da88d7

Change-Id: Ie202c072ab10783c4030af280023795e498d2523

Change-Id: I06a382917717906a0e5fdee57e296bab407c5348

The framework bits.

Change-Id: I9cbd649c7766284bfcf8846d2b5e129dd2731ee8

The comphelper::LibreOfficeKit bits. Also will need additions to the
libsofficeapp bits in desktop and then to the StatusIndicator implementation
in framework.

Change-Id: I15c2505bbf6439c07d1956685d0a6d2a22aefc58

Change-Id: I03ed512ba20206ed38428efe324f54f79abe1933
Reviewed-on: https://gerrit.libreoffice.org/15616Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: David Tardon <dtardon@redhat.com>
Reviewed-by: David Tardon <dtardon@redhat.com>