After the selection of a shape the shape name is selected in the Navigator
tab under the Drawing Objects entry.
It scrolls to the corresponding entry as well in case the scrollbar is
visible.
Change-Id: I298e8fe6bdab01eb20c53e1730812192c46770c5
Reviewed-on: https://gerrit.libreoffice.org/43566
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Bunth <btomi96@gmail.com>
...even if they implement PPCallbacks, so filtering them out in
HandleTranslationUnit was ineffective.
Change-Id: I9df8103a50739f3176e6d63accfd0334da7faa9a
Reviewed-on: https://gerrit.libreoffice.org/43575
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
For the Position and the Volume sliders
Change-Id: Ie7eee332b05e9a6cfc8165cf7b7b59695c58b458
Reviewed-on: https://gerrit.libreoffice.org/43571
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Previously m_bHideTabLeaderAndPageNumbers value was not restored after TOX
finish and so causing visibility problems with following hyperlinks.
Change-Id: I4ba5ce1f70e05d706d17d60e1a33a62995701f9e
Reviewed-on: https://gerrit.libreoffice.org/43310
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
* seems they work fine these days
* also removed magic number from fdo69649 test in favour of getting the
value straight from the document
Change-Id: Ife9d96eb413740b56b771df0d23e590f44f9452f
Reviewed-on: https://gerrit.libreoffice.org/43568
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
...that are included from various places. Change done in preparation of
loplugin:includeform.
Change-Id: I6507189a380a547321903d71e3cb425c37bb16ad
Reviewed-on: https://gerrit.libreoffice.org/43563
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...instead of through ../../... paths. Change done in preparation of
loplugin:includeform.
Change-Id: I1b4476f32573c2ef19d2a145e6e617b63006d40b
Reviewed-on: https://gerrit.libreoffice.org/43562
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...instead of implicitly next to the including file, in preparation of
loplugin:includeform
Change-Id: I954b6f7132db103c6b89a4ca1577b16f94e800c2
Reviewed-on: https://gerrit.libreoffice.org/43561
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...instead of implicitly next to the including file, in preparation of
loplugin:includeform
Change-Id: I4a666e8cd1cd3b1bf67af697be02879217dbc83a
Reviewed-on: https://gerrit.libreoffice.org/43560
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Some of the include files there had used
#include "..."
while others had used
#include <LibreOfficeKit/...>
for references among those include files. In preparation for
loplugin:includeform, consolidate on the latter (even if that's clearly a
misuse of the <...> form).
Change-Id: If142c844863e4e63b6fd8f2200732972860befd3
Reviewed-on: https://gerrit.libreoffice.org/43558
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
During parsing of the docx the paragraph without w:bidi
should take this value from style or from default paragraph properties,
Change-Id: Ie33f0d1cd3551c4053a47e6faf7dcac71765db65
tdf#87533 explicitly set writing mode value based on default properties
Change-Id: I3fcf514a901f0630d749ba0ddb6361d6db3ce1b5
Reviewed-on: https://gerrit.libreoffice.org/42895
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
If keyword does not correspond to any keyword in language
used, then English keywords are tested
Test done only if language may use localized keywords
Change-Id: Iace2470f311c9c02eb86b63d0ad5f6130f4e2f0b
Reviewed-on: https://gerrit.libreoffice.org/43260
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
...that are inclued from both vlc and vlc/wrapper. Change done in preparation
of loplugin:inlcudeform.
Change-Id: Ic7dc08b93d8a33b21dc64dfc0bfbe3952039f05b
Reviewed-on: https://gerrit.libreoffice.org/43556
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Merging attributes from table to top EditEngine has to be done
before colorizing with the range finder, as the resulting merged
default item set *overwrites* the items set.
Change-Id: I6561201de11344161f61d7d4cf6a7b79d76ba493
Wrong row number was calculated here. This ++nCurRow is usefull
only when headerlayout flag is set. It's a MSO compatibility flag
so it's not there by default in LO created tables.
Change-Id: Id7989d898f2647f1ba45ed95e0aa615e3b4fa311
Reviewed-on: https://gerrit.libreoffice.org/43552
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Project: translations 0703aea9337413756face54c3d7a89cc4a539a33
make msgfmt happy re 'msgid' and 'msgstr' entries do not both end with '\n'
Change-Id: Ib323bb112dac8da86f9ca062c1376f8f7d34e608
8d12e4ec8b "No -fstack-protect-strong for
gcc3_linux_aarch64/cpp2uno.cxx vtableSlotCall" had done that in the past (so
that setting up the x0/x1 return registers in vtableSlotCall is not clobbered
by the stack protector code), but gbuild details have apparently changed in the
meantime, so that gb_CXXFLAGS_COMMON's -fstack-protector-strong now ends up on
the compiler command line before what is covered by gb_Library_add_cxxobjects's
argument, so didn't get subst'ed to -fstack-protector. That caused Flathub
aarch64 builds to fail in CustomTarget_testtools/uno_test.
However, if both -fstack-protector-strong and -fstack-protector are present on
the command line, the second apparently wins, so use that hack for now.
(-fstack-protector-strong is only available since GCC 4.9, but -fstack-protector
is already available in our current baseline GCC 4.8.1, and even for a build on
that baseline it wouldn't hurt if cpp2uno.cxx was explicitly built with
-fstack-protector even if none of the other files were built with
-fstack-protector-strong.)
Change-Id: I9d78d2e5b08b7c0a4adb1531b482cd43617886f7
All of the RES_CHRATR_* items are poolable, hence we have
(pItem1 != pItem2) == (pItem1->Which() != pItem2->Which() || *pItem1 != *pItem2)
Move the redundant check to an assert() so we notice in case
somebody adds a new non-poolable RES_CHRATR.
Thanks to ccsheller for pointing me to this condition.
Change-Id: I9e0634946b8bede3f483bb8997f69de05beae64c
