This reverts the toolbarmanager.cxx part of
38839ae10cb565ff1977b1839de1c8278eac657b ("Remove the
ability to set tooltips in the toolbar xml files").
It is true that tooltips can't be set in xml files,
but toolbars can also be created/modified via the
UIConfigurationManager and LayoutManager APIs,
e.g. the test doc of i#105626 .
Change-Id: Ida1559e61e7fd9bd6dcdd7b7159bc5efe070c721
These are the simple removals, where it is obviously safe,
the more complex ones will come in separate commits
Change-Id: I7211945a6a5576354b60d9c709940ce9b674f308
Reviewed-on: https://gerrit.libreoffice.org/33828
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
so we can remove unnecessary calls to the OUString(literal) constructor
when calling constructors like this:
Foo(OUString("xxx"), 1)
Change-Id: I1de60ef561437c86b27dc9cb095a5deb2e103b36
Reviewed-on: https://gerrit.libreoffice.org/33698
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>
Seem UBSAN doesn't like my forced reinterpret_cast to set the Idles
Link in the Timer class. Now there are two possible solution:
1. convert all (DECL|IMPL).*_LINK call sites to use a Timer* or
2. split the inheritance of Idle from Timer again to maintain
different Link<>s and move all common code into a TimerBase.
While the 1st is more correct, the 2nd has a better indicator for
Idles. This implements the first solution.
And while at it, this also converts all call sites of SetTimeoutHdl
and SetIdleHdl to SetInvokeHandler and gets rid of some local Link
objects, which are just passed to the SetInvokeHandler call.
It also introduces ClearInvokeHandler() and replaces the respective
call sites of SetInvokeHandler( Link<Timer *, void>() ).
Change-Id: I40c4167b1493997b7f136add4dad2f4ff5504b69
in dependency of tdf#104101
Change-Id: I799f81adf4e4751fb505c84aa075363acf70f5a7
Reviewed-on: https://gerrit.libreoffice.org/33034
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
This results in a SolarMutex assert when creating a new Base document.
... and also implts_startListening() is looking less thread safe
than advertised.
Change-Id: I4635064733c16416f903dab4caee59fb2de3cb00
Drops a lot of duplicated code, as Idle is just a convenience
class for instant, mostly low priority timers.
Change-Id: I847592e92e86d15ab1cab168bf0e667322e48048
The destruction of the SwDLL object happens already through the normal
termination listener but the other termination listeners might still
depend on it. Also the outstanding events might need the SwDLL instance
to be still around.
This makes the destruction of the instance explicit and at a time when
it should be safe. We should use the same code for calc, impress, math
and base as well.
Change-Id: I50b8f30426f5a4a54e362e748fe962839abca73e
Reviewed-on: https://gerrit.libreoffice.org/32856
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
This will help us identify shutdown related crashes.
Change-Id: Id09c3dfdc94c430d5dcb2aebb017f17db80f17e5
Reviewed-on: https://gerrit.libreoffice.org/32485
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
The fix was silly and wrong, need to check m_xUIElement, not m_aName,
which may be set independently, see the confusing code in
ToolbarLayoutManager::requestToolbar().
Change-Id: I279088cb2516b0a19619b5647f15f738a2624edf
This reverts the following commits:
commit 722f4e1d86710f2facd37d7e040df9e1fd585e26
tdf#104573 - Assertion failed: SolarMutex not locked
commit f04ec99f5e6a543b8191ced61db4710c3c0de356
tdf#104573 - Assertion failed: SolarMutex not locked
commit 71b1e3ff6374c23e65200d3bcafca387d29af04f
tdf#104573 - Assertion failed: SolarMutex not locked when trying
commit e794ce1eef6730e5a46d5fb0aa6db2895ede85e7
verify that we hold the SolarMutex when ref-counting VclPtr
IRC discussion:
<noelgrandin> sberg, maybe I should revert this whole "VclPtr assert" series, I don't have mental bandwidth to sort this out properly now
<sberg> noelgrandin, what I fear is that you'll end up adding lots of SolarMutex locks to small places, where the proper fix would be to add it further out; and once such a dreaded recursive SolarMutex lock is in place (but needlessly so, once the proper fix is done), it's hard to clean that up again
<noelgrandin> sberg, yeah, in that case I'll just remove all of this, leave it for another day
Change-Id: Ie4f84b72b79a1b7e80164b5c7693af398c2c569a
Reviewed-on: https://gerrit.libreoffice.org/31946
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
ToolbarLayoutManager::createToolbar() may be called concurrently on
different threads, and then it can happen that both threads want to
create the same toolbar URL, see that it does not exist in line 457,
then both release the SolarMutex and create a new ToolBarManager
and the first inserts it and then the second overwrites it on line 514
without disposing the first one.
The non-disposed extra ToolBarManager is kept alive because it is
registered as a listener on the Frame. When the Frame::close() is
called, the ToolbarLayoutManager is disposed, and that disposes all the
ToolBarManagers it knows about, but not the extra one, which is
then un-ref'd and then has a live VclPtr m_pToolBar, which asserts
because the SolarMutex is not locked since commit
e794ce1eef6730e5a46d5fb0aa6db2895ede85e7.
(This commit is thanks to rr, which recorded the
JunitTest_framework_complex execution and allowed debugging this.)
Change-Id: I8f5333e8e36ac8ea347ef545e014ffc10501aebb
