...the code was in this odd shape ever since
bf4154eb5307ec8c35f000fd1df39ef3abb2eb6d "initial import"
Change-Id: Ic931b99267bb6501f15119636f13391f1d065ed4
After the cleanup, the stuff there really stands on its own (and the
remaining usage of select1st/2nd is more descriptive than lambdas).
Change-Id: I0aba131d5dc550189f8130d167dc94167e404540
Reviewed-on: https://gerrit.libreoffice.org/17806
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Replace lambdas used to select the first/second member of a pair with
the new simplified select1st/2nd from o3tl/compat_functional. There
should be no side effects due to this change.
Change-Id: I17f37796e0c4defe96a10aa491d192adb9eebb89
Reviewed-on: https://gerrit.libreoffice.org/17656
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Remove all instances of classes that are derived from the now
depreciated unary_function and binary_function with lambda expressions.
Change-Id: Iab662159b8b8554e10dfe6886ee803da78a937ed
Reviewed-on: https://gerrit.libreoffice.org/16631
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
When image is set to a Button control the correspoding graphic object
lives only temporarily, after the graphic is copied from the graphic
object it's destroyed so save can't find it by graphic ID.
Use the same solution which works for ImageControls: use a graphic object
member for the control, so save can find it.
Change-Id: If99a3efc4727a07df9d2daaefbdacc9565920005
...to avoid lots of loplugin:staticmethods warnings. Also enables DBG_ASSERT
etc. also for --enable-debug builds in addition to --enable-dbgutil builds.
Change-Id: Ib89ecd9ab8ce7abb2c64790ace248b31f9d2b64d
Not very useful these days, since we have the css:: prefix to reduce
verbosity.
Found with a search like:
git grep -nP 'typedef .*uno::Reference.*<.*>\s+\w+;'
| grep -v 'std::'
Change-Id: I16f41c53837ec5c613545ae45df38b0daddcbadd
Reviewed-on: https://gerrit.libreoffice.org/16730
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
At least OutputDevice::acquire/release use a plain unguarded int and ++, --, so
apparently rely on the SolarMutex being locked whenever they are called. Fixed
those places that caused "make check" to fail for me when temporarily adding
DBG_TESTSOLARMUTEX() to OutputDevice::acquire/release. (A recurring pattern is
that a class fails to ensure the SolarMutex is locked around the destruction of
non-null VclPtr members.)
Change-Id: I77cba6f3908f2de1b516ce28f1c3c43b3f57a9c5
Idea originally from caolan.
Found using the following command:
find . -name *.cxx | xargs /opt/local/bin/grep -zlP '(?m)if\s*\(\s*\w+\s*\)\s*delete\s+\w+\;'
Change-Id: I3338f4e22193a6dfd6219c8c75835224a3392763
