Change-Id: I9f7ccd372a570dc4dea98983c51419dce83f8be8

Change-Id: Iedc5e8caafda868db853fdf328fbdc99bbf28e20

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

Project: help  cc5bb5cd5316199307fcafa59583314f040b8733

Change-Id: Ice1cf2ce078b130130c44952ec2be0f8642f21a8

Change-Id: I7ff2411aed76aa74c8c0d111962773e7af12a7df

Change-Id: I9654da23886d52968c3c95300cc7ad4f772cbb8d

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

Change-Id: Ie9ddc5a42116720e0602d7fb38360f01b71df69c

Was first introduced by 538c13f3

We should process clipboard formats in order of descriptive-/
usefulness -- however png/bmp are special cases (as browsers
will add an html equivalent to their clipboard when copying raw
images, with the raw image being the preferred target format)
and were therefore moved up in the paste-preference list,
mistakenly it was assumed that GDI Metafiles should be subject
to the same treatment, but it appears that Word (and Wordpad?)
will provide both RTF (preferred) and GDI for formatted text.

Change-Id: I731986fc9d70e7aeb64e53764e32cfec3e27eca1

Accidentally removed GDI metafiles from calc too.

This reverts commit a96a7ce5.

The passed m_aCurrentRow becomes out-of-date as soon as the current row changes.
This also hides an implementation detail of ORowSet to ORowSet(Data)Column.

Change-Id: Ib9188743e5dd6dec240e9f5fd3fd9655c6761abc
Reviewed-on: https://gerrit.libreoffice.org/10792Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Tested-by: Lionel Elie Mamane <lionel@mamane.lu>

Change-Id: I61cb1c608a7de8efc63533085e86c6c17c05f545
Reviewed-on: https://gerrit.libreoffice.org/10793Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Tested-by: Lionel Elie Mamane <lionel@mamane.lu>

This reverts commit b398ed8e:  "Aug 06 10:11:53
<sberg> moggi, b398ed8e broke
CppunitTest_chart2_xshape, very many attributes in
chart2/qa/extras/xshape/data/reference/fdo75075.xml have wrong values now;
what's the best way to fix? manually fixing fdo75075.xml (assuming the new
values are even correct?) looks /very/ tedious.  better revert the commit for
now?"

Change-Id: I178cb5591c95cc5587ac56662abf808bfca7a336

Conflicts:
	dbaccess/UIConfig_dbaccess.mk
	dbaccess/source/ui/misc/WizardPages.src

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

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

Change-Id: I849daf0ddee370775fda73e04739e69acbc64246

Change-Id: I47d9dab17d4891d05cf7497e53026bc801f2726b

XSun is a relic from Solaris 10 / SPARC.

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

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

When importing CSV with multiple lines in a cell, it looks as if some content
was lost.  It is not, it is in the spreadsheet, but looks very confusing, and
only way to get around that was to let the heights be recalculated.

It seems that the large CSV still opens in reasonable time even with this
change in.

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

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

For whatever reason the tinderboxes still try to regenerate the
autotools based files, even after applying the generated file
change after the template changes.

These patches aren't needed, as the original problem is the CPPFLAGS
environment visibility, so we drop them.

Change-Id: Idb5caf662c997221337416686313101ad2193e40

Change-Id: Ibcf63b3d15223ca9f217406231f97c20f3663819

...similar to what has been done for svx/sdtmfitm.hxx in
6a2ea81c "Remove unused ctors" and
68969cc6 "Consistency around SdrMetricItem."

(SdrEdgeLine1DeltaItem::Clone had been recently---and in retrospect needlessly
---introduced in 596ec6f5 "Missing
SdrEdgeLine1DeltaItem::Clone override" before
3efa3ad7 "SdrEdgreLine*DeltaItem::Put/QueryValue
are same as underlying" revealed that SdrEdgeLine1DeltaItem was a needless
derivation of SdrMetricItem.)

Change-Id: I154d32d46a7c01c792aa4e812cf576d4d749e0c9

...CntInt32Item::Put/QueryValue

Change-Id: I21602be0f4ba9d9e34a379a86d524b05976b0c8f

The libgltf configure.ac script changes the autotools user variables
CFLAGS and CXXFLAGS, which is not allowed and can overwrite user
settings (which it does for the -D_GLIBCXX_DEBUG flag).

So this moves the special compile settings to seperate variables and
passes them to AM_CXXFLAGS and AM_CPPFLAGS, so the library actually
gets compiled with libstdc++ debug objects.

Change-Id: I00989f5fb629a6aac43ee5a2eb287b0491a3b86d

Change-Id: I7d733a509f8256d0c2bfbb4bbd91ed6924452051

This seems to save another nearly 300k; and I guess the compiler will optimize
it better than using the unordered_map.

Change-Id: I5df5cd2afe3f4bedad69e1e3477211842c40a90c

Change-Id: Id5beb6af8c32ab45d7e31120d38966f8fe4d5418

Change-Id: Id0fde0a76fbcb63c13c943a0caec0d715886f039

Change-Id: Ifd471e49cb167af48a9173762812164890e00791

Change-Id: I476d7e26d35e38d458f62c01f478ed2b54eed355

...similar to what has been done for svx/sdtmfitm.hxx in
6a2ea81c "Remove unused ctors" and
68969cc6 "Consistency around SdrMetricItem."

Change-Id: Icdeff7f37901f99158bb00de5e912c181bf3e688

Change-Id: Ife159630b7e68e8e346619853b8285f46dcf275b

Change-Id: Icd6028d2b84db106351084936d00b44ad73f2592

Change-Id: I4417318988ef70639cbcec9d776c783ad69c3990

Change-Id: I02928097f049e8f3cbefbc872b570b2d2b072658

Change-Id: I3be867391f42b6c7e2ce7fb1f1f553f5a5558699