Most probably that was related to "pulsating" buttons that haven't
been used since 10.9. Whether the code even worked (made buttons
pulsate) on 10.9 anyway is unclear.
Much of the code in this file uses various HITheme (Carbon?) API that
as far as I know is long since deprecated and undocumented. It's weird
that it still compiles, and that it doesn't get caught by the private
API use checking when submitting to the the Mac App Store, in the
LibreOffice Vanilla case.
This change reduces the busy looping in Dialog::Execute() even when
nothing happens (no user input, no mouse movement) when displaying a
dialog.
Change-Id: I9c62db608f637aa5d8493176feb2873f6426fd00
This restores compatibility for API users who called getByName() on the
bitmap table and expected that the result can be set as a value for the
GraphicURL property.
The case is similar to the Writer images, which was handled in commit
587803ba46 (sw TextGraphicObject: handle
XBitmap for GraphicURL, 2018-08-08) already.
Change-Id: I3740a68989b306425d0d6c4d4e350ac163cb4170
Reviewed-on: https://gerrit.libreoffice.org/64069
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
It is much over a year since we bumped to 10.9, so it is time.
Bumping to 10.10 will allow us to with good conscience get rid of some
code that (presumably) tries to emulate some aspects of OS X user
interface look that went away in 10.10. See tdf#114839.
Change-Id: Ic41f73d8e59a40c4696069af85bb3ff33146086c
Reviewed-on: https://gerrit.libreoffice.org/63880
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
This way it can't happen that we open a menu or context menu, the user
switches away (loosing focus) and a leftover floating window is still
there.
Handle this at the same place where we stop blinking the cursor on focus
loss.
Change-Id: I4321e8e3fa1d3f8976c0a1fa29c6a182972023bf
Reviewed-on: https://gerrit.libreoffice.org/64053
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Missed this one in Change-Id: I47f9ae10a0fd967729ff6e83c1a312aa49e1d13c
Change-Id: Ibb825a922e7d7fcc31456386935b3a847642ebf0
Reviewed-on: https://gerrit.libreoffice.org/63966
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
it is no more complex, and it saves us the construction of an
intermediate vector
Change-Id: Ie92c2970c5b10805d7bcfc0cc2a74378f2cbda08
Reviewed-on: https://gerrit.libreoffice.org/64039
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This changes how the list items are identified in the code, making
use of the support for item ids in comboboxes introduced in commit
83cefb5ceb.
Change-Id: I69390c8f9d32b77454e2935cf28b38ea44be8ffd
Reviewed-on: https://gerrit.libreoffice.org/63238
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9ee3318c79d3b59f272a2a5f89c38b26afa05974
Reviewed-on: https://gerrit.libreoffice.org/63775
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
macOS's linker can take a -filelist argument, in place of taking the
list of object files to link on the command line. This is a more limited
version of "response files" as used elsewhere in the code base, and by
using it we make it far less likely that a linker invocation will hit
ARG_MAX.
A standard LibreOffice build probably won't hit ARG_MAX on macOS just
yet, but it's not far off - some LDFLAGS are enough to tip it over the
edge, which is what prompted me to fix the issue. If not fixed, a few
more object files will probably break LibreOffice builds on macOS! An
example of another large program that has encountered this issue is
Thunderbird, which implemented the same fix[1].
The changes I've made to use -filelist are adapted from the code
elsewhere in gbuild that creates response files, but this is slightly
different because -filelist files are a bit different - they can only
contain object files, as opposed to arbitrary linker arguments, and
arguments are separated by newlines rather than spaces.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=837618
Change-Id: I01b9126aad95056c3dc82f941dea4fd43f95d0f2
Reviewed-on: https://gerrit.libreoffice.org/64010
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
(*) also make it more obvious what XMLShapeExportFlags::SIZE represents
Change-Id: Ie63edf0f2827f171542037b819ebe7d55e090275
Reviewed-on: https://gerrit.libreoffice.org/63948
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Apparently import isn't always properly reading some of these
strings, so it is just garbage being round-tripped in some cases.
Let's just avoid that until such time as import might be fixed.
I couldn't readily identify the import problem. It even happens with
version eWW8 files and also TestBeltAndBraces() didn't seem to
prevent the problem.
These crashes are due to reading garbage:
/srv/crashtestdata/files/doc/ooo78311-1.doc
-DISTRICT_COURSE_OUTLINE_TEMPLATE.doc
/srv/crashtestdata/files/doc/kde79024-2.doc
-Ü2_Blanko.doc
/srv/crashtestdata/files/doc/ooo24395-1.doc
-stateapp-emp.doc
/srv/crashtestdata/files/doc/abi9921-1.doc
/srv/crashtestdata/files/doc/ooo59101-1.doc
-Hovedblankett.DOC
/srv/crashtestdata/files/doc/fdo48097-1.doc
-BR1010.doc
Change-Id: Iceaa53760867f06c73ab900c57f197dbc0fb8e65
Reviewed-on: https://gerrit.libreoffice.org/63938
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
This reverts commit 74d6476a04. Developer
Toolset 7 has apparently not yet been installed on vm139 (the node exclusively
executing this job), see
<https://ci.libreoffice.org/job/lo_callgrind_linux/6525/console>:
> checking for gcc... /opt/rh/devtoolset-7/root/usr/bin/gcc
> checking whether the C compiler works... no
> configure: error: in `/home/buildslave/lode/jenkins/workspace/lo_callgrind_linux':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> Error running configure at /home/buildslave/lode/jenkins/workspace/lo_callgrind_linux/autogen.sh line 296.
... since initial commit d791366863
V560 A part of conditional expression is always false: (nArse == 0x2225).
Change-Id: I4afb30f0c6c067d0e42e3fa15e5c2b2c1caa73b3
Reviewed-on: https://gerrit.libreoffice.org/63996
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
