Change-Id: Ib873ca03a2552dc0405236ed87040672ba359e5e

Change-Id: I8319bf10310d55e2f29de8103d983e34a53f87df

Change-Id: I6aba45a70a9ebee65be34af1036bb515fd2a22b7

Change-Id: Icd472e91b222907e2cdcbdba1b78b33c44eff566

...to eventually support writing to dconf (see TODO).

Even when writing somewhere else, it may still be useful to read from the
current "user:" location, so a new convention was introduced to
CONFIGURATION_LAYERS types that support write-back:

- A leading "!" indicates that the layer is indeed used for write-back (probably
in addition to reading from it).  For backwards compatibility (when users use
own settings of CONFIGURATION_LAYERS, instead of depending on the value in the
shipped fundamental ini-file), no prefix on the "user:" is now interpreted the
same as a "!" prefix.

- A leading "*" indicates that the layer is not used for write-back (but only
for reading from it).

Change-Id: I399cc7bfe927db50586834f9630c184aaa2153f2

Change-Id: I1582443cf6799dd73a3909660d524eaacbc2d909

Change-Id: Ibebe470d0d0c00bfcaf7b3cb90aa102e8101b7bc

Change-Id: Ice9a860ca839d37308b5c2f2eb639852fefe1d15

Change-Id: I1fe771f01edb0ce14da01146191cfe3f48958966

under gnome-shell which doesn't put an "X" to close things in
the wm decorations if the GDK DIALOG hint it set

prior to tdf#72587 this was a modeless dialog and in that case
it doesn't have a parent, in which case the hint is NORMAL
and it used to get close decorations.

easist thing to do is to remain modal so the crashes and
confusion of tdf#72587 remain fixed but add a close to it to
behave like all the other dialogs do

Change-Id: I64450be0ad1bc7b06196e1342679e15b60fc60d9

Change-Id: I352f14741dd9346bb41d4e3233b256898809773e

Change-Id: I37d4d4a933cfd1df8dc8f8258e270bd3dbcef714

First Patch do not solved the problem
The evaluation of the 0 is here
http://opengrok.libreoffice.org/xref/core/xmloff/source/text/txtparae.cxx#615
and this methode "xNumRule->getCount()" get back the 0.

Change-Id: I2a8f53199b0819f36a7d3e1887c75089143b29a9
Reviewed-on: https://gerrit.libreoffice.org/18228Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

It turns out that in this case it hurts performance if we go via
invaliation-then-paint instead of direct painting when double-buffering
is not enabled.

Related commits:

- beb4aa21 (SwViewShell::ImplEndAction:
  avoid direct paint, 2015-06-29) and
  c9175a1b (SwViewShell::ImplEndAction:
  avoid direct PaintDesktop(), 2015-07-03) globally avoided direct paints
- 222f10e7 (tdf#93096 sw: fix selection
  with keyboard outside current view, 2015-08-18) restored direct paint
  when non-double-buffering for the second commit, this one does the
  same for the first

Change-Id: Ida0c6917a8cdec74209bd64813c7876d4fa61b8a

Change-Id: Ia73125ba2e547f87c1f28bdc917333346a01a251

Change-Id: I3b2ce8ef79c4bc0dde8ba43f96ca4e97a71dd2cd

Change-Id: Ibf32ef644222a59c5fe6a9736ff64739ab24b74f

Change-Id: I9332fa9b805e702fb56067efc308aff09310f603

and

coverity#1321597 Resource leak in object

Change-Id: I6e9e517a394bea60c1f0550b17bacd653eee5cbc

Change-Id: I5a2e61200333ca57af990d3d7be3899da836472a

Change-Id: I909c225dd9bd92763ae24b62854a9217fc2e2a0e

Adapt to 1ba1a21a (tdf#73071 Enable
styles content panel in calc and fix spacing issue), but the second
assert should be ideally 100 and not 99 what it is actually, so comment
that out for now.

Change-Id: I551640c9db57285942a897eeb57515939ed3510d

Project: dictionaries  03a4a7b13f28c2c8df08cf6d5049fde97d6b4244

tdf#93514 remove Czech thesaurus

Change-Id: I40ebd1ca223fe7950ed3280c43a51a3dfbd0070e

Change-Id: Idb24848ecd15d3970cdec3e080eb0f8ead0358ed

Change-Id: Idaf322c53cb8955bb88e18a6d79fd800dc48621d

with the variadic variants.

Change-Id: I663029b736489b81ed4ccb5f7bd657fbaf091bdf
Reviewed-on: https://gerrit.libreoffice.org/18206Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Regression from http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d8ecad569fd7a254902da154ed8057ec61f3a83
Thank you Matthew Francis for having found the root cause!

Change-Id: I4128368a5f5df6a9fc5f7668fb1f8f330b5795b9
Reviewed-on: https://gerrit.libreoffice.org/18210Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

9a6cdce3 was trying to fix the problem
with exposing deprecated vars and functions in system's error_code.hpp
include file by patching bundled boost version.  This approach would
only make sense, when upstream version is going to be fixed ASAP. Apply
another approach, and follow the same pattern as applied in external
libraries, by defining

  -DBOOST_ERROR_CODE_HEADER_ONLY \
  -DBOOST_SYSTEM_NO_DEPRECATED

instead of patching bundled boost version.  This way, the code would
work with unpatched system boost 1.59 final as well.

Change-Id: I8684ca458ea4a5b7d7c3c3acfe7c14a6d19bc665
Reviewed-on: https://gerrit.libreoffice.org/18201Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>

...as happens in CppunitTest_sw_filters_test with
sw/qa/core/data/ww8/pass/CVE-2015-2467-1.doc, first at:

> filter/source/msfilter/msdffimp.cxx:1477:17: runtime error: load of value 8193, which is not a valid value for type 'MSO_Anchor'
>  DffPropertyReader::ApplyCustomShapeTextAttributes(SfxItemSet&) const filter/source/msfilter/msdffimp.cxx:1477:17
>  DffPropertyReader::ApplyAttributes(SvStream&, SfxItemSet&, DffObjData&) const filter/source/msfilter/msdffimp.cxx:2694:9
>  SvxMSDffManager::ImportShape(DffRecordHeader const&, SvStream&, void*, Rectangle&, Rectangle const&, int, int*) filter/source/msfilter/msdffimp.cxx:4332:21
>  SvxMSDffManager::ImportGroup(DffRecordHeader const&, SvStream&, void*, Rectangle&, Rectangle const&, int, int*) filter/source/msfilter/msdffimp.cxx:4119:39
>  SvxMSDffManager::ImportGroup(DffRecordHeader const&, SvStream&, void*, Rectangle&, Rectangle const&, int, int*) filter/source/msfilter/msdffimp.cxx:4106:39
>  SvxMSDffManager::ImportGroup(DffRecordHeader const&, SvStream&, void*, Rectangle&, Rectangle const&, int, int*) filter/source/msfilter/msdffimp.cxx:4106:39
>  SvxMSDffManager::ImportGroup(DffRecordHeader const&, SvStream&, void*, Rectangle&, Rectangle const&, int, int*) filter/source/msfilter/msdffimp.cxx:4106:39
>  SvxMSDffManager::ImportObj(SvStream&, void*, Rectangle&, Rectangle const&, int, int*) filter/source/msfilter/msdffimp.cxx:4033:16
>  SvxMSDffManager::GetShape(unsigned long, SdrObject*&, SvxMSDffImportData&) filter/source/msfilter/msdffimp.cxx:6210:23
>  SwWW8ImplReader::Read_GrafLayer(long) sw/source/filter/ww8/ww8graf.cxx:2502:17
>  SwWW8ImplReader::ReadChar(long, long) sw/source/filter/ww8/ww8par.cxx:3634:17
>  SwWW8ImplReader::ReadChars(int&, int, long, long) sw/source/filter/ww8/ww8par.cxx:3436:27
>  SwWW8ImplReader::ReadText(int, int, ManTypes) sw/source/filter/ww8/ww8par.cxx:3974:22
>  SwWW8ImplReader::CoreLoad(WW8Glossary*) sw/source/filter/ww8/ww8par.cxx:5175:9
>  SwWW8ImplReader::LoadThroughDecryption(WW8Glossary*) sw/source/filter/ww8/ww8par.cxx:5773:19
>  SwWW8ImplReader::LoadDoc(WW8Glossary*) sw/source/filter/ww8/ww8par.cxx:6045:19
>  WW8Reader::Read(SwDoc&, rtl::OUString const&, SwPaM&, rtl::OUString const&) sw/source/filter/ww8/ww8par.cxx:6167:20
>  SwReader::Read(Reader const&) sw/source/filter/basflt/shellio.cxx:175:18
>  SwDocShell::ConvertFrom(SfxMedium&) sw/source/uibase/app/docsh.cxx:258:22
>  SfxObjectShell::DoLoad(SfxMedium*) sfx2/source/doc/objstor.cxx:790:23
>  SwFiltersTest::filter(rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, SfxFilterFlags, SotClipboardFormatId, unsigned int, bool) sw/qa/core/filters-test.cxx:112:20

Change-Id: Iafc548b5ba21a985521790770732f7f03e2485c9

This reverts commit 6fd71992. Kendy says the
original problem can't be reproduced anymore, and most unexpected flickering
goes away with this for my nvidia card.

Also, it's a good idea in general to keep PFD_DOUBLEBUFFER and
WGL_DOUBLE_BUFFER_ARB in sync, which is now the case.

Change-Id: I7a809d1c85be4206c01720d5de9b0a5617a59c87

...as happens in CppunitTest_sw_filters_test with
sw/qa/core/data/ww8/pass/CVE-2015-2431-1.doc:

> sw/source/filter/ww8/ww8par4.cxx:294:76: runtime error: reference binding to null pointer of type 'const SfxItemSet'
>  SwWW8ImplReader::ImportOle(Graphic const*, SfxItemSet const*, SfxItemSet const*, Rectangle const&) sw/source/filter/ww8/ww8par4.cxx:294:23
>  SwWW8ImplReader::ReadChar(long, long) sw/source/filter/ww8/ww8par.cxx:3611:35
>  SwWW8ImplReader::ReadChars(int&, int, long, long) sw/source/filter/ww8/ww8par.cxx:3436:27
>  SwWW8ImplReader::ReadText(int, int, ManTypes) sw/source/filter/ww8/ww8par.cxx:3974:22
>  SwWW8ImplReader::CoreLoad(WW8Glossary*) sw/source/filter/ww8/ww8par.cxx:5175:9
>  SwWW8ImplReader::LoadThroughDecryption(WW8Glossary*) sw/source/filter/ww8/ww8par.cxx:5773:19
>  SwWW8ImplReader::LoadDoc(WW8Glossary*) sw/source/filter/ww8/ww8par.cxx:6045:19
>  WW8Reader::Read(SwDoc&, rtl::OUString const&, SwPaM&, rtl::OUString const&) sw/source/filter/ww8/ww8par.cxx:6167:20
>  SwReader::Read(Reader const&) sw/source/filter/basflt/shellio.cxx:175:18
>  SwDocShell::ConvertFrom(SfxMedium&) sw/source/uibase/app/docsh.cxx:258:22
>  SfxObjectShell::DoLoad(SfxMedium*) sfx2/source/doc/objstor.cxx:790:23
>  SwFiltersTest::filter(rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, SfxFilterFlags, SotClipboardFormatId, unsigned int, bool) sw/qa/core/filters-test.cxx:112:20

Change-Id: I4482bc5d8e0c2646e7c8667a231a78311b557e89

Change-Id: If882d49c3abe236c8ca5af502a38947b98e34d5e

SubdivideBezier creates polygons which are more exact for drawing
in opengl when drawing hairline PolyLines - so let's use that with
AA line drawing.

Change-Id: I490fd0f19361b5fc9e1f4e03851c1ae1a1f75f71

Change-Id: Idf8c958161a92ba73dfb60da9a10ab9d59be7c2d

... during token string creation, as an empty column specifier is the
last thing we want to see.. which still can happen though if the stored
name was synced with the existing cell data and copying the older
original name was not possible, for example due to name clashes.

Change-Id: I6a0d313a02efafc092f0bbf7725fb3b3e77e486f

Change-Id: I7fc96e3b7754bb3f4718f9142c75ee82aef0a22c

Change-Id: I744ff8be96bda2fff61c8fc23a067fdd9b2d4930

Change-Id: Ieab07fcd9bc89d81829d636bb854db37ad2ba9e0

Change-Id: I9ad88c0f7f935a247f0f21c7aa206312435ecafc