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>

The assignment in the 3rd ctor is actually executed after the use from
loadUI().

(regression from 39078c24)

Change-Id: I34b3d7fb9d6c4637d15c7865e6034f2c9d968b99

Change-Id: Ib959da6f4dab0b290955e8b786d6efeef7f307b0

Apparently -1 is used for invalidated ones.

Change-Id: I31901ff9f1caf3d011e476e220cec71669f5a356

Change-Id: I2554c77245eb2c22201b6e680ab42db666b2ee8b

Change-Id: I901d934d1c2bdf6f15760292481091eb740dfda1

Change-Id: I75f4be6d13fc10a801f105c5033bc288bf87c29b
Reviewed-on: https://gerrit.libreoffice.org/15564Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: If94504f08cca6dcab009142cc18799bafecb3ece

Change-Id: Ic0a084fe7392ae5a407a367fb67a5a1837a2ca14

This code was like that ever since 84a3db80
"initial import."  From other uses of SvxOpaqueItem, the best bet appears to be
RES_OPAQUE.

Change-Id: I19de8fac4f41716d9c2a73bda4a8cea200ae99f8

Change-Id: If870f88d1d83db8bd436ac1bb9a1c676c34605b5

Change-Id: I46dadf9be542990ef18d78a54d7ebce3c3df80f9