Also drop unused framework/inc/fwkdllapi.h
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9e79266f273b778f4a8bd3330b1b0353a2e01a61
Reviewed-on: https://gerrit.libreoffice.org/81927
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
new statusbar element property mandatory=true/false to determine
if this element can be hidden if total statusbar width is not
enough to fit all elements.
marked some calc and draw statusbar elements as not mandatory.
Change-Id: I20e26d3c4bd865e94ea48632a1e97d55f3fa712f
Reviewed-on: https://gerrit.libreoffice.org/56443
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...so that it no longer has a m_aXMLAttributeNamespace member that the user-
provided copy ctor did not copy. (Which was presumably by accident, but appears
to not have had bad consequences due to how XMLNamespaces::adNamespace is only
called before the copy ctor is called in SaxNamespaceFilter::startElement,
framework/source/fwe/xml/saxnamespacefilter.cxx).
Found by new -Wdeprecated-copy of GCC trunk towards GCC 9.
Change-Id: I0701ecdfbef9c078a09ed411f4d9ccd166271aae
Reviewed-on: https://gerrit.libreoffice.org/56469
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
had to change the structure of the plugin considerably, was too messy to
structure it to do the calculations on a per-function basis
Change-Id: I4edee7735f726101105c607368124a08dba21086
Reviewed-on: https://gerrit.libreoffice.org/40516
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The issue of 362d4f0cd4 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
When destroying the static vcl::CommandInfoProvider aProvider from
vcl::CommandInfoProvider::Instance (vcl/source/helper/commandinfoprovider.cxx)
during exit, it releases its mxCachedGlobalAcceleratorConfiguration reference on
GlobalAcceleratorConfiguration
(framework/source/accelerators/globalacceleratorconfiguration.cxx), which may
get destroyed, whose base class framework::XCUBasedAcceleratorConfiguration
(framework/source/inc/accelerators/acceleratorconfiguration.hxx) has a
salhelper::SingletonRef<framework::KeyMapping> member, whose destructor
(include/salhelper/singletonref.hxx) uses
salhelper::SingletonRef<framework::KeyMapping>::SingletonLockInit::operator ()'s
static osl::Mutex aInstance.
If, during construction, the instantiation of
salhelper::SingletonRef<framework::KeyMapping>::SingletonLockInit::operator ()'s
static osl::Mutex aInstance finishes before the instantiation of
vcl::CommandInfoProvider::Instance's static vcl::CommandInfoProvider aProvider,
the corresponding atexit cleanup actions will be recorded in the right order,
causing the above chain of calls to find the static Mutex still alive when used
from within the static CommandInfoProvider's destruction.
However, vcl::CommandInfoProvider's mxCachedGlobalAcceleratorConfiguration is
only set to css::ui::GlobalAcceleratorConfiguration::create in
vcl::CommandInfoProvider::GetGlobalAcceleratorConfiguration, so the
instantiation of the static Mutex instance can finish after the instantiation of
the static CommandInfoProvider instance, recording the atexit cleanup actions in
the wrong order, causing the static Mutex to be used after destruction.
This occasionally caused PythonTest_sfx2_python to hang during exit for me on
Linux, where trying to lock a destroyed pthread mutex can apparently deadlock.
rtl::Static does away with the need to do anything in the destructor, at the
expense of always keeping the instance alive until exit (and not being able to
recreate an already destroyed instance during exit, but code that would require
that behavior would probably already be broken to begin with), so the order of
creation of the CommandInfoProvider and GlobalAcceleratorConfiguration instances
becomes less of a concern.
Change-Id: Id6e3860ad9e5b7045980a0b9bf9eaef2e24129bb
The following properties have been removed:
toolbar:bitmap
toolbar:property
toolbar:width
toolbar:userdefined
This should have no impact on existing functionality or AddOns, since these properties were not in use.
Change-Id: I07574f8102648ee0713379be8cb0b605d2c76364
It was possible to set a tooltip for a certain toolbar entry.
However, this hasn't been used since that tooltip needed to be repeated for each occurence of the same command.
Instead, a TooltipLabel property has been introduced lately (see 9c2f197e8e).
This doesn't affect extensions (They have their own format to specify toolbars).
Change-Id: I0f0fd05b310bb49dd5b4123e31d3e7fec997dd15
Reusing the same xml format as the menubar, except that
a popup menu use menu:menupopup as the root element.
Change-Id: I2987af0dc698b09aeeb757cff828617515bc3009
