If we removed something that is a link to a real file from our list of images
to pack, but that real image is not in the list of images to pack, add it in
instead so the real image does get packed
Change-Id: I71bcbdf872a59194a1d94f287dda8fc27e4a6464
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99961
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Unfortunately we need this on Android for the tablets, otherwise the
sidebar lacks the icons.
Also it is not easily possible to use the isLOKMobilePhone() check here,
because that is per-view in general, and handled in sfx in particular,
making it hard to use here in vcl.
This reverts commit 9a38b194ee.
Change-Id: I2b599e884ad4d00b7c246743c180a5324c9a143d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99300
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
This only handles lists with PositionAndSpaceMode::LABEL_ALIGNMENT.
TODO: handle PositionAndSpaceMode::LABEL_WIDTH_AND_POSITION.
TODO: handle NumberingType::BITMAP.
It doesn't align number according to Adjust, since that requires to
use a tab stop at the number position with appropriate alignment, and
it's unclear how would that interact with LabelFollowedBy modes other
than LISTTAB.
When first tab stop position is greater than ParaLeftMargin, Writer
uses left margin as implicit tab stop position, thus in this case
list appearance is different from processed text appearance.
In case of justified paragraphs, space after number (which does not
participate in justification when part of numbering) becomes part
of justification after conversion to text.
Change-Id: I88ad6617f8a09307ecad9d28edee92a59c68a4d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99939
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Typically in these OutputDevice methods, the record-to-metafile case the
MetaFile is already written to before the test against mbOutputClipped to
determine that output to the current device would result in no visual output
(due to the output being outside the bounds of the device).
In this case the metafile is written after the test, so we must continue past
mbOutputClipped if recording to a metafile. It's typical to record with a
device of nominal size and play back later against something of a totally
different size.
Change-Id: Id1249b10f919165582f7de65b4cdc4d48074abaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99900
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Change-Id: I00f6fea1ee93bf2598d0cfde73fb2de17f0eb379
--- and not # of columns - 1.
Life is already too confusing to add that complication to it.
Not quite NFC. There is one place where a column
count of 1 would have set column separator/space.
I didn't think that would be necessary.
Change-Id: I87a7bfb5e746e8b7e4c57ddf40b0740d0ef35aba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99930
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
For the content of the selection it should not make a difference if that range
is "backward" or "forward", but the latter looks cleaner.
Change-Id: Ibc27ac257c9338f9b17ace10fbec938b1db394eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99932
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
They had been added with 27798238ec "uitest :
Avoid any timing issue in test_insert_hyperlink" and
1cdda798de "Further timing issues with
test_insert_hyperlink", but 63049e98a6 "Reliably
set up controls of hyperlink dialog in constructor" now argues that they are
probably not necessary after all: For one, they had presumably been added as
blind fixes, without actually understanding what's going on (that's at least
true for the second, monkey-see-monkey-do one by me). And for another, after I
had seen their failures frequently with my local ASan+UBSan Linux build, I
haven't seen them at all in lots of executions of that test with the
63049e98a6 fix included.
So lets assume that those "magic" calls are indeed not necessary after all. If
we run into trouble again, they can be added back.
Change-Id: I6f4417c9fd243758a03a4de05270f342e7147d27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99931
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The recently added test_insert_hyperlink in
sw/qa/uitest/writer_tests3/hyperlinkdialog.py (UITest_writer_tests3) has often
failed on slow builds like <https://ci.libreoffice.org/job/lo_ubsan/>, by
hitting the assert in rtl_uString_newFromSubString as described at
<https://lists.freedesktop.org/archives/libreoffice/2020-July/085594.html> "Race
with SwEditWinUIObject::get_state during UITest_writer_tests3?" However, it
turns out that the actual race is rather different from what was assumed there:
The initial content of the dialog's controls like "target" and "indication" were
only set during the first SvxHlinkCtrl::StateChanged(SID_HYERLINK_GETLINK),
which is called from the SfxBindings machinery based on a timer. When that
happens, any text that has already been typed into those controls by the user
would be overwritten again. But in normal GUI operations, the timer fires so
quickly that the user has not yet typed anything into those controls. On the
other hand, for a typical (fast) execution of test_insert_hyperlink, the whole
test has already been executed when the timer fires, so the overwriting is not
noticed.
But for a slow execution of the test, the timer may e.g. fire after the
"indication" control's content ("link") has been typed in (which
SvxHlinkCtrl::StateChanged will reset to the empty string) and before the dialog
is closed (so instead of "link", the empty string will be added to the Writer
document, and obtaining the text selection of length 4 will crash as described
in the email). (Also, the two calls to wait_until_property_is_updated added
with 27798238ec "uitest : Avoid any timing issue
in test_insert_hyperlink" and 1cdda798de "Further
timing issues with test_insert_hyperlink" probably just address other symptoms
caused by the same underlying issue, and should no longer be necessary with this
fix. But cleaning that up is left for a follow-up commit.)
The solution is to set up the controls' initial content already in the
constructor, so when the SfxBindings timer fires for the first time, it no
longer calls StateChanged because that state has already been recorded.
However, that caused the focus no longer to be set to the "target" control when
the dialog is opened, at least for the gen and svp VCL backends (which caused
the .uno:HyperlinkDialog-related tests in
desktop/qa/desktop_lib/test_desktop_lib.cxx, CppunitTest_desktop_lib, to fail
because GetFocusControl returned null): The first call to
SvxHlinkCtrl::StateChanged -> SvxHplinkDlg::SetPage now happens during the
constructor, before the dialog is shown, so the request to grab the focus in
SetInitFocus was ignored. The solution to that problem is to shift setting the
initial focus to the first call of SvxHpLInkDlg::Activate, which is called
whenever the dialog gains focus.
Change-Id: Ib4d5e06dfc21014ccec546565426fa2d27e63ce1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99903
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...during CppunitTest_sd_import_tests_smartart:
> oox/source/drawingml/diagram/diagramlayoutatoms.cxx:656:50: runtime error: signed integer overflow: 1924451 - -2147483647 cannot be represented in type 'int'
> #0 in oox::drawingml::AlgAtom::layoutShape(std::shared_ptr<oox::drawingml::Shape> const&, std::__debug::vector<oox::drawingml::Constraint, std::allocator<oox::drawingml::Constraint> > const&, std::__debug::vector<oox::drawingml::Rule, std::allocator<oox::drawingml::Rule> > const&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:656:50
> #1 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::AlgAtom&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:202:19
> #2 in oox::drawingml::AlgAtom::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:386:14
> #3 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16
> #4 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:243:5
> #5 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14
> #6 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16
> #7 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:245:5
> #8 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14
> #9 in oox::drawingml::LayoutAtomVisitorBase::visit(oox::drawingml::ForEachAtom&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:98:20
> #10 in oox::drawingml::ForEachAtom::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:167:14
> #11 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16
> #12 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:245:5
> #13 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14
> #14 in oox::drawingml::Diagram::addTo(std::shared_ptr<oox::drawingml::Shape> const&) at oox/source/drawingml/diagram/diagram.cxx:122:30
> #15 in oox::drawingml::loadDiagram(std::shared_ptr<oox::drawingml::Shape> const&, oox::core::XmlFilterBase&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, oox::core::Relations const&) at oox/source/drawingml/diagram/diagram.cxx:356:15
> #16 in oox::drawingml::DiagramGraphicDataContext::onCreateContext(int, oox::AttributeList const&) at oox/source/drawingml/graphicshapecontext.cxx:252:9
> #17 in non-virtual thunk to oox::drawingml::DiagramGraphicDataContext::onCreateContext(int, oox::AttributeList const&) at oox/source/drawingml/graphicshapecontext.cxx
> #18 in oox::core::ContextHandler2Helper::implCreateChildContext(int, com::sun:⭐:uno::Reference<com::sun:⭐:xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx:94:34
> #19 in oox::core::ContextHandler2::createFastChildContext(int, com::sun:⭐:uno::Reference<com::sun:⭐:xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx:191:12
> #20 in non-virtual thunk to oox::core::ContextHandler2::createFastChildContext(int, com::sun:⭐:uno::Reference<com::sun:⭐:xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx
> #21 in (anonymous namespace)::Entity::startElement((anonymous namespace)::Event const*) at sax/source/fastparser/fastparser.cxx:432:44
> #22 in sax_fastparser::FastSaxParserImpl::callbackStartElement(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, unsigned char const**) at sax/source/fastparser/fastparser.cxx:1246:21
> #23 in (anonymous namespace)::call_callbackStartElement(void*, unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) at sax/source/fastparser/fastparser.cxx:305:18
> #24 in xmlParseStartTag2 at workdir/UnpackedTarball/libxml2/parser.c:9588:6
> #25 in xmlParseTryOrFinish at workdir/UnpackedTarball/libxml2/parser.c:11378:14
> #26 in xmlParseChunk__internal_alias at workdir/UnpackedTarball/libxml2/parser.c:12280:13
> #27 in sax_fastparser::FastSaxParserImpl::parse() at sax/source/fastparser/fastparser.cxx:1046:21
> #28 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun:⭐:xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:866:9
> #29 in sax_fastparser::FastSaxParser::parseStream(com::sun:⭐:xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:1369:13
> #30 in oox::core::FastParser::parseStream(com::sun:⭐:xml::sax::InputSource const&, bool) at oox/source/core/fastparser.cxx:121:15
> #31 in oox::core::FastParser::parseStream(com::sun:⭐:uno::Reference<com::sun:⭐:io::XInputStream> const&, rtl::OUString const&) at oox/source/core/fastparser.cxx:129:5
> #32 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) at oox/source/core/xmlfilterbase.cxx:402:21
> #33 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&) at oox/source/core/xmlfilterbase.cxx:331:12
> #34 in oox::ppt::PresentationFragmentHandler::importSlide(rtl::Reference<oox::core::FragmentHandler> const&, std::shared_ptr<oox::ppt::SlidePersist> const&) at oox/source/ppt/presentationfragmenthandler.cxx:610:17
> #35 in oox::ppt::PresentationFragmentHandler::importSlide(unsigned int, bool, bool) at oox/source/ppt/presentationfragmenthandler.cxx:348:13
> #36 in oox::ppt::PresentationFragmentHandler::finalizeImport() at oox/source/ppt/presentationfragmenthandler.cxx:499:17
> #37 in oox::core::FragmentHandler2::endDocument() at oox/source/core/fragmenthandler2.cxx:54:5
> #38 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun:⭐:xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:872:36
> #39 in sax_fastparser::FastSaxParser::parseStream(com::sun:⭐:xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:1369:13
> #40 in oox::core::FastParser::parseStream(com::sun:⭐:xml::sax::InputSource const&, bool) at oox/source/core/fastparser.cxx:121:15
> #41 in oox::core::FastParser::parseStream(com::sun:⭐:uno::Reference<com::sun:⭐:io::XInputStream> const&, rtl::OUString const&) at oox/source/core/fastparser.cxx:129:5
> #42 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) at oox/source/core/xmlfilterbase.cxx:402:21
> #43 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&) at oox/source/core/xmlfilterbase.cxx:331:12
> #44 in oox::ppt::PowerPointImport::importDocument() at oox/source/ppt/pptimport.cxx:145:17
> #45 in oox::core::FilterBase::filter(com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) at oox/source/core/filterbase.cxx:485:49
> #46 in oox::ppt::PowerPointImport::filter(com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) at oox/source/ppt/pptimport.cxx:223:24
> #47 in SfxObjectShell::ImportFrom(SfxMedium&, com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> const&) at sfx2/source/doc/objstor.cxx:2251:34
> #48 in sd::DrawDocShell::ImportFrom(SfxMedium&, com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> const&) at sd/source/ui/docshell/docshel4.cxx:399:39
> #49 in SfxObjectShell::DoLoad(SfxMedium*) at sfx2/source/doc/objstor.cxx:738:23
> #50 in SdModelTestBase::loadURL(rtl::OUString const&, int, std::shared_ptr<SfxAllItemSet>) at sd/qa/unit/sdmodeltestbase.hxx:181:30
> #51 in SdImportTestSmartArt::testText() at sd/qa/unit/import-tests-smartart.cxx:250:37
As discussed on IRC:
> Jul 31 18:52:58 <vmiklos> sberg: yes, that looks reasonable, clearly the
> expectation is that there is at least one element, in which case that
> nVertMin grows from 0 and nVertMax shrinks from
> std::numeric_limits<sal_Int32>::max()
> Jul 31 18:54:43 <vmiklos> sberg: sounds like i made that mistake in
> acdde3c643, but recently i added a test that
> now uncovered the problem :)
Change-Id: I0ee11dbab568af788f9e2786c3dca2c1a5e1ee08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99902
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Copy all version infos in English
Follow-up to 56b2214c3a
Change-Id: Id093305261ec957137c56f61048c660e80e5c795
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99773
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Move 3 functions from ImplGetObjectURL(sal_uInt32 nPos), ImplGetObjectURL(const
INetURLObject& rURL) and ImplGetObjectPos(const GalleryObject* pObj) to
GalleryObjectCollection as they deal with the m_aObjectList directly, and
rename them respectively.
Change-Id: I1e02b345d706c57db8801441fc955af9157cf565
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99789
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
When constraints request a width which is larger than 100%, we scale
down. Then rules decide which children should be scaled down and which
ones stay as-is.
This commit adjusts the size of children which have no rule, but their
size has a constraint that they're a fraction of a scaled down child.
Change-Id: I0a007d82f49f18951215afb1bfe8c0f1328ecd41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99875
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
since...
commit 263e5726c7
Date: Sat May 30 21:21:26 2020 +0700
Resolves tdf#133268: Update Colibre color palette
a quirk in the vcl treeviewbox is that with the missing
image the inline-edit of the row doesn't work as its autocancelled
by the attempt to resize the row due to the missing image
Change-Id: I02ae0d4a3833c9e59380e7b28791f0d64a3da3ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99874
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Gracefully handle the case where the SalInstance returns an
empty Reference when trying to create clipboard.
Primary selection support on Wayland has only recently been
added to the relevant KDE components ([1], [2]), and an empty
Reference would be returned for the qt5/kf5 VCL plugin when
trying to create create a clipboard for primary selection
in a Plasma Wayland session with that functionality not yet being
available.
Regression from commit 05d286e006
("vcl/clipboard: create instances with uno constructors", 2020-07-07).
[1] https://invent.kde.org/plasma/kwayland-server/-/merge_requests/15
[2] https://invent.kde.org/plasma/kwin/-/merge_requests/27
Change-Id: Ia9016f56b775003b2ffe81a6f3bf44f411ad39a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99871
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
