Change-Id: I7d81b9b616fc4b4b324d959282b6a71ce681fba5

Change-Id: Ie77596a51a6a37e9f59a6ba14bdde7994efd29ad

Change-Id: Iace701d7473e874cc8df64349b71faa4a5493d5e

Change-Id: I72ef9570ac9e7b4cb4afc2319725743098722d31

Change-Id: I0a224a90a3e99d12809d40612b1e66d7c023aebc

Change-Id: Icd5f9f4b8e1c48176fdb73c954e1c4b7d0811516

Let the player decide what to do when the duration is zero, and start()/stop() was called.

Change-Id: I17027349e8d61f7b114e193a769402c04a64f3f3

Change-Id: I83a99e333a6c62bf7779e3fbbcc3e5af38bb2ca5

Change-Id: Ie4a912cc3c144c47a4bb59551ebb1c68f302569e

Thank you Lionel and Tor!
(see http://nabble.documentfoundation.org/Strange-part-in-connectivity-source-drivers-jdbc-tools-cxx-td4110680.html)

Change-Id: Ibbe68b8b3d12e4dfacf7f66bb3adbc2fd831d1a5

Change-Id: I06749af90bed6a43f3fb6b3b5ceb61d5fbbc7c02

Change-Id: I0aada90e9ea4e9fc92fd9c365aa9c7171cb10a55

so move out of the globals headers and drop their public visibility
markup

Change-Id: Ie0a852c962a9d05488022397e83152d1c73cfa29

==3768== 512 bytes in 1 blocks are possibly lost in loss record 25,532 of 28,010
==3768==    at 0x4A06965: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3768==    by 0xB52FA41: __gnu_cxx::new_allocator<bool>::allocate(unsigned long, void const*) (new_allocator.h:104)
==3768==    by 0xB52EC00: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_allocate_node() (stl_deque.h:533)
==3768==    by 0xB52DE4E: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_create_nodes(bool**, bool**) (stl_deque.h:627)
==3768==    by 0xB52C624: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_M_initialize_map(unsigned long) (stl_deque.h:601)
==3768==    by 0xB52ACA0: std::__cxx1998::_Deque_base<bool, std::allocator<bool> >::_Deque_base(std::allocator<bool> const&, unsigned long) (stl_deque.h:461)
==3768==    by 0xB5296D3: std::__cxx1998::deque<bool, std::allocator<bool> >::deque(std::allocator<bool> const&) (stl_deque.h:791)
==3768==    by 0xB52840E: std::__debug::deque<bool, std::allocator<bool> >::deque(std::allocator<bool> const&) (deque:73)
==3768==    by 0xB52786B: framework::UndoManagerHelper_Impl::UndoManagerHelper_Impl(framework::IUndoManagerImplementation&) (undomanagerhelper.cxx:221)
==3768==    by 0xB525882: framework::UndoManagerHelper::UndoManagerHelper(framework::IUndoManagerImplementation&) (undomanagerhelper.cxx:879)
==3768==    by 0x6872683: sfx2::DocumentUndoManager_Impl::DocumentUndoManager_Impl(sfx2::DocumentUndoManager&) (docundomanager.cxx:88)
==3768==    by 0x6870FB6: sfx2::DocumentUndoManager::DocumentUndoManager(SfxBaseModel&) (docundomanager.cxx:227)
==3768==    by 0x687A272: SfxBaseModel::getUndoManager() (sfxbasemodel.cxx:1677)
==3768==    by 0x260E562A: (anonymous namespace)::getUndoManager(com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) (PagePropertyPanel.cxx:74)
==3768==    by 0x260E6C60: sw::sidebar::PagePropertyPanel::PagePropertyPanel(Window*, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, SfxBindings*) (PagePropertyPanel.cxx:189)
==3768==    by 0x260E593C: sw::sidebar::PagePropertyPanel::Create(Window*, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, SfxBindings*) (PagePropertyPanel.cxx:101)

The SfxBaseModel creates the DocumentUndoManager on demand at
sfx2/source/doc/sfxbasemodel.cxx:1685

m_pDocumentUndoManager is a rtl::Reference but debugging into the
acquire/release I see that the
DocumentUndoManager::acquire/DocumentUndoManager::release forward to those of
SfxModelSubComponent which forward them to its rModel without doing anything
else, so the implementations of
DocumentUndoManager::acquire/DocumentUndoManager::release don't actually do
anything directly to the DocumentUndoManager itself so there is nothing that
will really release it.

Either the rModel needs to explicitly destroy it somehow, given that the
acquire/release delegate responsibility to it, or the whole thing is addled.

I rather feel it's addled, so implement as a normal WeakImplHelper1, but
cowardly in addition also keep acquire/release on the rModel.

Change-Id: Ib52544a9276fd8d9d489ad6b6afda12498cc39fa

Change-Id: I2311b33034c281cba66d7cce80a6556e27b2b322

Change-Id: I80ce89351e2a8dbb1d9d928b673a8589fd651584

Change-Id: Ia2f482fb7737e61cfc42966dbc7af6e1cdb3b41d

Change-Id: I0fc77b50792e48be175ab7cc151509e097676849

when throwing exceptions

Change-Id: I6edfb6b6745499f802b0e3c0e096a36fb7c32aac

.. now that we have a default value for that parameter

Change-Id: I54d6b0a0a01ce2f2e5168ada0c427424de0477bc

Change-Id: Id1d7971639b2496dbe0274423ff4150d9295e8d6

Change-Id: I1c07a44e7d318478bcb2561d29ea53a9475e4b1f

Change-Id: I95817ea44b6793d4a80b74b32f3b5477c6169b26

Change-Id: I86aea12318d4e21ccadd97ad2820e31bd4580c99

Change-Id: I4bbaf97fe8c5def441ca106c26ad312281ed352f

Change-Id: Iac63a5d60478e5cd8e2b77c889c7b312d3d15f67

The SvxRuler binds the SID_ATTR_PARA_LRSPACE, and its indents and the
positions of tab stops depend on the values it gets from there; in LO
4.0 the value came from the SwView::StateTabWin() but now it comes from
SwTextShell::GetAttrState(), and the difference is that the former does
a special request to get the NumRule indents as LR-space.

(regression from d02f75a8)

Change-Id: I548ce188655555f2473cb3973ce7aeb927d1a404

Change-Id: I223e0587b5a82c1617a0e79a002472070d2d4402

Change-Id: I8641b8c0b478dd23d312fb4e8eed8aa98eb7035e

Change-Id: Id045cbeaa057fd264a50f83fb58bbee60df71299

Change-Id: I09d0bfe06e3fbb93f65587a847133fb1b3a3f2b2

Change-Id: I8e3adae6ef23c7750de0bcb5934d5743e24fde58

See http://nabble.documentfoundation.org/Questions-about-getCppuType-td4106361i20.html

Change-Id: I05d0b026e1ef2088472a42ee20e0823df1588428

This reverts commit 72827968.

Change-Id: Ie79bb1d57d05c0a1e51733bacc1b103f44ddc153

Change-Id: I2e6b04f32bd0aca6da41e04e26f33bd894c53d7e

Change-Id: Ib9ef14b4ce38f93f590473913a308a967343c75d

bt:
0x00002aaac837cd3c in rtl::OUString::copy (this=0x7ffffffec760, beginIndex=-2147483595) at /home/julien/compile-libreoffice/libreoffice/include/rtl/ustring.hxx:1464
0x00002aaac87604ea in ScInterpreter::ScRight (this=0x8a6b7a0) at /home/julien/compile-libreoffice/libreoffice/sc/source/core/tool/interpr1.cxx:8106
0x00002aaac879be5c in ScInterpreter::Interpret (this=0x8a6b7a0) at /home/julien/compile-libreoffice/libreoffice/sc/source/core/tool/interpr4.cxx:4150

So apply similar fix http://cgit.freedesktop.org/libreoffice/core/commit/?id=37d7d115dd346ba7a713a5a18d90fc48a0d35072
to scRight

Change-Id: I576e82cd033f0e0e5f9e9cbb9dd5f569782bbbc4

Conflicts:
	chart2/source/view/main/GL3DRenderer.cxx

Change-Id: I8b74a1e7f32c30b6a908c0870bbeacc00cdea444

c47db038 was an attempt to fix fdo#52547,
i.e. to make sure that the actual image data was stored if an image was
being pasted from a browser (where the clipboard contains both image data,
but also an html construct which would instead embed the image from the
web). However the new ordering inadvertently meant that strings would
be preferred to html -- i.e. copying a mixture of text+image from a
webpage would result in only the text being stored.

The new ordering causes images copied from the browser to still have
the actual image data stored (rather than a link in the case of the
html being stored), but html is still preferred to plaint text.

(This is primarily as a result of Firefox (and possibly other browsers)
changing their clipboard to contain an html construct which links to the
original image, in addition to the raw image data-- and html previously
being preferred to images in the paste ordering meant that the linked
version would be pasted by default, which is not the expected result
when copying an image.)

Change-Id: Ice9b37cf3dd25d8cdb0e04f19a6b2f3661018564

Change-Id: I24e45810cb154310d8e35982e2ef100cf5746e2b