Only on macOS, the SDK used to expect javac etc. in a Commands sub-dir (which
Apple's JDK 1.6.0 has but Oracle's JDK 1.8.x don't). However, at least both
Apple's latest JDK 1.6.0 (as available via <https://support.apple.com/kb/DL1572>
"Download Java for OS X 2015-001") and any recent Oracle JDK 1.8.x (like
jdk1.8.0_121.jdk) have a Home sub-dir that contains a "standard" sub-tree with
bin sub-dir etc., like on other platforms. So consistently make the SDK use
that instead.
This removes the JAVABIN Make variable from settings.mk. It is assumed to not
be used by client code.
Change-Id: Ie0ad647f489528444dfd399c2f00500b772d3288
The problem in callnk.cxx was that when selecting 1 char to the right
using keyboard, and exiting field boundary, nCmp pointed to previous
position (inside field), and then compared to position to the left
(which also may be inside field), thus missing call change link (and
read-only state change). Seems that this was a mistake in commit
740efbb1daf26828f70dc785c1e107f67706286b.
In pam.cxx, if cursor was to the left of field, and then selected
1 char to the right to cross field's boundary, then both PaM's point
and mark had same fieldmark, but point was outside, and mark inside,
and as code didn't check this condition, so read-only state wasn't
properly set.
Unit test is augmented to check the second problem.
Change-Id: I7323e53eeb261b4ccdc0f9e36cc0956b373f104d
Reviewed-on: https://gerrit.libreoffice.org/33790
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The #include was introduced in
96c1ae1d8e78ae8b9bd7d4001645cad24d62b720 with an #if on
HAVE_FEATURE_OPENGL, but that #if was later removed.
Change-Id: I70f839d5224e0a77a1640a5e23cbe64656c9cb1b
This reverts commit 4739b31dafc5154a2c7d6b3f0ee90686863656f0.
Apparently, passing a param of type css::uno::Exception to Any
will record precisely a css::uno::Exception in that Any, losing
any subtype information, which this commit changed.
since the latter is rather slow
Change-Id: Ib73cdb923585580777c2265b561c1808e93b2baa
Reviewed-on: https://gerrit.libreoffice.org/33585
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
all the call sites are passing an uno::Exception subtype
Change-Id: I6de1f00810e063e75ef620314561d7e2d6445ada
Reviewed-on: https://gerrit.libreoffice.org/33657
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
So add to them instead of just assigning. In the bugdoc the initial
values were zero, but maybe in some other cases they aren't.
Change-Id: I3d399fe4aab9260817f171d4e69388a19eb85d21
just the simple and obvious case for now, of a local var being allocated
and deleted inside a single local block, and the delete happening at the
end of the block
Change-Id: I3a7a094da543debdcd2374737c2ecff91d644625
Reviewed-on: https://gerrit.libreoffice.org/33749
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Text portion level background in Writer text was working already, as
Writer paints its background explicitly, and then uses no text fill
color in the metafile (that is turned into a PDF later).
However, text fill color is used for Writer shape text and also in
Impress. The rectangle is not just the text itself, but also the ascent
/ descent region, this matches the desktop rendering result.
Change-Id: I644007ade43a8b9e663890643b826ae12c427ea5
Reviewed-on: https://gerrit.libreoffice.org/33781
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...as is the case for external/breakpad's
google_breakpad::ExceptionHandler::SignalHandler (though that one appears to be
careful to check that its additional arguments are not garbage, cf. the
"Sometime, Breakpad runs inside a process where some other buggy code..."
comment in
workdir/UnpackedTarball/breakpad/src/client/linux/handler/exception_handler.cc).
Seen when JunitTest_framework_complex run under ASan/UBSan happened to trigger
an assert,
> soffice.bin: vcl/source/app/dbggui.cxx:47: void ImplDbgTestSolarMutex(): Assertion `ImplGetSVData()->mpDefInst->CheckYieldMutex() && "SolarMutex not locked"' failed.
> sal/osl/unx/signal.cxx:349:13: runtime error: call to function google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*) through pointer to incorrect function type 'void (*)(int)'
> (instdir/program/libsofficeapp.so+0xb7eab0): note: google_breakpad::ExceptionHandler::SignalHandler(int, siginfo_t*, void*) defined here
> #0 0x7f6cefc21693 in (anonymous namespace)::callSystemHandler(int) sal/osl/unx/signal.cxx:349:13
> #1 0x7f6cefc1f3e1 in (anonymous namespace)::signalHandlerFunction(int) sal/osl/unx/signal.cxx:422:9
> #2 0x7f6cedbc95bf (/lib64/libpthread.so.0+0x115bf)
> #3 0x7f6ced20491e in __libc_signal_restore_set /usr/src/debug/glibc-2.24-33-ge9e69e4/signal/../sysdeps/unix/sysv/linux/nptl-signals.h:79
> #4 0x7f6ced20491e in __GI_raise /usr/src/debug/glibc-2.24-33-ge9e69e4/signal/../sysdeps/unix/sysv/linux/raise.c:55
> #5 0x7f6ced206519 in __GI_abort /usr/src/debug/glibc-2.24-33-ge9e69e4/stdlib/abort.c:89
> #6 0x7f6ced1fcda6 in __assert_fail_base /usr/src/debug/glibc-2.24-33-ge9e69e4/assert/assert.c:92
> #7 0x7f6ced1fce51 in __GI___assert_fail /usr/src/debug/glibc-2.24-33-ge9e69e4/assert/assert.c:101
> #8 0x7f6cb60cdad5 in ImplDbgTestSolarMutex() vcl/source/app/dbggui.cxx:47:5
> #9 0x7f6cbd337fb9 in DbgTestSolarMutex() tools/source/debug/debug.cxx:74:9
> #10 0x7f6cb3c98abf in vcl::Window::ReleaseGraphics(bool) vcl/source/window/window.cxx:900:5
...
Change-Id: I2625541e0b9e50f9723e61e0cbff0e6c77d0fb9f
lets just leave the toolbar active the whole time, seems
to make more sense anyway wrt being allowed to keyboard
into it to paste/insert special character
Change-Id: I174fb707c4c7fd21d95461cc93323eb6d8970818
Makes it easier to push various infobars without specifiying the
colors manually.
Change-Id: I0f861ba02409a42ba2ae767a1ca7634eaf0e7aef
Reviewed-on: https://gerrit.libreoffice.org/33777
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
because root entries have UserData of type SwContentType while children have
UserData of type SwContent (both inherit from SwTypeNumber)
Change-Id: Iab7a4caaca5dfdae16aa4f6ede565e26aa4c73c9
VisualStudio2013IntegrationGenerator recently doesn't work
with the new relative paths in GbuilParser.
this patch does this, now it works fine with all relative paths.
what is missing it's in the .vcxproj:
<NMakeBuildCommandLine>
<NMakeCleanCommandLine>
<NMakeReBuildCommandLine>
these still work with absolute path but i start now on working this
Change-Id: I19610097edc11be67b4f7fd9f32b6683d334cc2d
Reviewed-on: https://gerrit.libreoffice.org/33735
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
