Age | Commit message (Collapse) | Author |
|
clear previous build results, but leave results of this build in place
Change-Id: Ia2857c7cfb33ac0227323d90828818ceb6e693a8
|
|
after commit 96ef1973d0309cc8a6aa9482f2fe35804f49c414
loplugin:useuniqueptr in SwTextPortion::CreateHyphen
Change-Id: Idb3b652c328ca20d049a1002088ded797f8ed098
Reviewed-on: https://gerrit.libreoffice.org/60517
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
of a paragraph sequence by inspecting every paragraph in a
"redline" range. Before this fix, all empty paragraphs of
a multiparagraph deletion reappeared as normal text in the DOCX
export.
Change-Id: I928504bdbd8c04673698e8f34c0b608eb3ecc5fc
Reviewed-on: https://gerrit.libreoffice.org/60503
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
After tdf#119689/gradient has been added to the context menu
the same should be done for transparency
Change-Id: I3932a1c4dff99c2b8876b0196de7d974b8dcdb31
Reviewed-on: https://gerrit.libreoffice.org/60478
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
|
|
Use range-based loop or replace with functions from std algorithm.
Change-Id: I5b1859da37c2a6c6e5e70602287bfc2ada951893
Reviewed-on: https://gerrit.libreoffice.org/60463
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It seems that on iOS, where we don't have any Java, Python, BASIC, or
other scripting, the only thing that would use the C++/UNO bridge
functionality that invokes codeSnippet() was cppu::throwException().
codeSnippet() is part of what corresponds to the code that uses
run-time-generated machine code on other platforms. We can't generate
code at run-time on iOS, that has been known forever. Instead we have
used some manually written assembler to handle it instead. We used to
have a Perl script to generate a set of code snippets for different
cases, different numbers of parameters of the called function and
whatnot, but that went away at some stage some year ago. (It is
unclear whether that broke the C++/UNO bridge on iOS, or whether the
stuff continued to work even after that.)
Anyway, this handwritten assembly, or the manual construction of
internal data structures for exceptions, or something else, seemed to
have bit-rotten. Exceptions thrown with cppu::throwException() were
not catchable properly any longer.
Instead of digging in and trying to understand what is wrong, I chose
another solution. It turns out that the number of types of exception
objects thrown by cppu::throwException() is fairly small. During
startup of the LibreOffice code, and loading of an .odt document, only
one kind of exception is thrown this way... (The lovely
css::ucb:InteractiveAugmentedIOException.)
So we can simply have code that checks what the type of object being
thrown is, and explicitgly throws such an object then with a normal
C++ throw statement. Seems to work.
Sadly the cppu::getCaughtException() API still needs some inline
assembly in the C++/UNO brige. That seems to work though, knock on
wood.
This commit also adds a small "unit test" for iOS, copied from
cppuhelperm to ImplSVMain(). Ideally we should not copy code around of
course, but have a separate unit test app for iOS that would somehow
include relevant unit tests from source files all over the place.
Later.
Change-Id: Ib6d9d5b6fb8cc684ec15c97a312ca2f720e87069
Reviewed-on: https://gerrit.libreoffice.org/60506
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
TODO says:
"in case of binary fields, this "getString" below is extremely expensive"
In this case, swap the terms of the if to hope to gain a little.
Change-Id: I4ef7b3bf5a9cbe49f7d56462d02ab274cbfd0025
Reviewed-on: https://gerrit.libreoffice.org/60509
Tested-by: Jenkins
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
|
|
* Update helpcontent2 from branch 'master'
- tdf#115254 Some branch bookmarks are'nt working 30
Module desktop
Change-Id: I9a965d52ccfa4de55b1b0c8453022336a9336e81
Reviewed-on: https://gerrit.libreoffice.org/60516
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
* Update helpcontent2 from branch 'master'
- tdf#115254 Some branch bookmarks are'nt working 29
Module extensions, scanner + spropctrl
Change-Id: I3984f52dd383e3d9153312418964af513408640b
Reviewed-on: https://gerrit.libreoffice.org/60515
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
* Update helpcontent2 from branch 'master'
- tdf#115254 Some branch bookmarks are'nt working 28
Module extensions sabpilot
Change-Id: Ice04b3b4a73ff3004bc367d4ed0da93edaef3fc5
Reviewed-on: https://gerrit.libreoffice.org/60514
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
* Update helpcontent2 from branch 'master'
- tdf#115254 Some branch bookmarks are'nt working 27
Module filter
Change-Id: I57015107b3dfa2536987dc187e2fe40eec1cf32d
Reviewed-on: https://gerrit.libreoffice.org/60513
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
* Update helpcontent2 from branch 'master'
- tdf#115254 Some branch bookmarks are'nt working 26
Module formula
Change-Id: I938d27a30497e3f9cc1880e3eb3cff82dedec2e4
Reviewed-on: https://gerrit.libreoffice.org/60512
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
* Update helpcontent2 from branch 'master'
- tdf#115254 Some branch bookmarks are'nt working 25
Module fpicker
Change-Id: I23f736f131e5cd7a7d9b2900d2423302cbbb87db
Reviewed-on: https://gerrit.libreoffice.org/60511
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
* Update helpcontent2 from branch 'master'
- tdf#115254 Some branch bookmarks are'nt working 24
Module reportdesign
Change-Id: Iefdc13ab35e4ac475f93b76d6b9bb9b202985c8b
Reviewed-on: https://gerrit.libreoffice.org/60510
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
The interesting part of the layout of page 2 is:
- frame #40 is a section frame with a text frame which is in a list
("A")
- frame #48 is a section frame after that, with the same top=19213
Given that frame #40 has height > 0, they overlap when the page is
rendered. What happens is:
- frame #40 grows
- there are other section frames between #40 and #48 in-between, but
they don't have an SwSection
- these frames are skipped
- then the position of #48 is invalidated
So the next time we calculate the position of #48, we look the last
skipped (previous) section frame (which still has top=19213, since its
position was not invalidated above), and since its height is 0, we
conclude that our current top=19213 is valid after all.
This is like this since commit 84a3db80b4fd66c6854b3135b5f69b61fd828e62
(initial import, 2000-09-18), so leave the code there that invalidates
not only the next frame, but all the way down to the first
non-SwSection-less-SwSectionFrame. But instead of just invalidating the
last frame, invalidate the in-between SwSection-less-SwSectionFrames as
well.
In practice this did not cause a problem in case the document has no
layout cache. If it does, then the frames are created on pages hinted by
the cache, then later moved to their final place. In practice this bug
was visible only in this later case. (I.e. such a layout cache can be
only created if the machine that saved the document last time does not
have the fonts needed by the document installed; and then the document
is opened on an other machine which has those fonts.)
Change-Id: I02ae9f63d0b4b5e9d014df53ed2cf21a04b15090
Reviewed-on: https://gerrit.libreoffice.org/60502
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Not sure how it worked in LibreOfficeLight.
Change-Id: I0991b13a7538581642f530bf45a1bba1b1b644d5
Reviewed-on: https://gerrit.libreoffice.org/60505
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
A unit test to conserve the current behavior which fixes 117187 partly.
Change-Id: If10feb7de52963db2f6974581cac54fd1ae7e0e6
Reviewed-on: https://gerrit.libreoffice.org/60319
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I3f6d0b5047d85038a9dec9022950de9cb7df4977
Reviewed-on: https://gerrit.libreoffice.org/60498
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic43f007af4480b358916c2b27796a9b248ea9eb7
Reviewed-on: https://gerrit.libreoffice.org/60496
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Idee779cea587e11f6d0f7902182c9394e73d46eb
Reviewed-on: https://gerrit.libreoffice.org/60488
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
...that recently started to hit quite often during JunitTest_chart2_unoapi, when
the main thread is painting windows and calls ChartView::createShapes (which
calls impl_deleteCoordinateSystems, which clears m_aVCooSysList) while an URP
thread executes chart::WrappedPropertySet::getPropertyValue and calls
ChartView::getExplicitValuesForAxis (which calls findInCooSysList, which
iterates over m_aVCooSysList), all apparently without locking access to
m_aVCooSysList. (See e.g. the below backtraces from
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/14432/console>, where
both threads operate on chart::ChartView instance 0x2633140.)
I assume this issue has always been there, and has only been made noticeable
with recent 3e62ac3e9ef2f6759d8faca2c012dba51c314ba5 "loplugin:useuniqueptr in
VCoordinateSystem", which changed the implementation of
impl_deleteCoordianteSystems from O(1) swap-and-clear to plain O(n) clear of
m_aVCooSysList, which extends the time span in which the thread executing
findInCooSysList can find an inconsistent m_aVCooSysList (and see in the below
backtrace how much code is apparently executed during the destruction of
m_aVCooSysList's VCartesianCoordinateSystem elements).
And indeed, <https://bz.apache.org/ooo/show_bug.cgi?id=109770>
"ChartView::getExplicitValuesForAxis accessing destroyed VCoordinateSystem"
found apparently the same issue already in 2010, and the swap-and-clear was
introduced as a means to address the race in
590a1a5225623eb922e63b02b62e711d153e9d55 "chart43: #i109770#
ChartView::getExplicitValuesForAxis accessing destroyed VCoordinateSystem". (So
the "//#i109770#" comment should have been removed from
impl_deleteCoordinateSystem already when
3e62ac3e9ef2f6759d8faca2c012dba51c314ba5 dropped the swap; catching up on that
now.)
For a proper fix, there appears to be no constitent existing locking scheme for
ChartView (appart from a few scatter SolarMutexGuards). Lets be bold and see
whether it works to put the whole bodies of (at least, for now) createShapes and
getExpliticValuesForAxis under SolarMutexGuards. (Which means the
SolarMutexGuard in createShapes2D can go, as it is exclusively called from
createShapes.)
> Thread 2 (Thread 0x2ae81cbd2840 (LWP 10147)):
> #0 0x00002ae81dee4f9a in __gnu_debug::_Safe_iterator_base::_M_attach(__gnu_debug::_Safe_sequence_base*, bool) () at /lib64/libstdc++.so.6
> #1 0x00002ae822e0a685 in __gnu_debug::_Safe_iterator_base::_Safe_iterator_base(__gnu_debug::_Safe_sequence_base const*, bool) (this=0x7ffedb73c598, __seq=0x2acc2f0, __constant=false) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/debug/safe_base.h:89
> #2 0x00002ae822f75c6a in __gnu_debug::_Safe_iterator<std::__cxx1998::_Deque_iterator<SfxBroadcaster*, SfxBroadcaster*&, SfxBroadcaster**>, std::__debug::deque<SfxBroadcaster*, std::allocator<SfxBroadcaster*> > >::_Safe_iterator(std::__cxx1998::_Deque_iterator<SfxBroadcaster*, SfxBroadcaster*&, SfxBroadcaster**> const&, std::__debug::deque<SfxBroadcaster*, std::allocator<SfxBroadcaster*> > const*) (this=0x7ffedb73c598, __i=, __seq=0x2acc2a0) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/debug/safe_iterator.h:152
[...]
> #44 0x00002ae846166609 in chart::VCartesianCoordinateSystem::~VCartesianCoordinateSystem() (this=0x28c2b60) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/axes/VCartesianCoordinateSystem.cxx:64
> #45 0x00002ae8461767af in std::default_delete<chart::VCoordinateSystem>::operator()(chart::VCoordinateSystem*) const (this=0x28e4190, __ptr=0x28c2b60) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/unique_ptr.h:67
> #46 0x00002ae8461737d3 in std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >::~unique_ptr() (this=0x28e4190) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/unique_ptr.h:184
> #47 0x00002ae84626e295 in std::_Destroy<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > >(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*) (__pointer=0x28e4190) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_construct.h:93
> #48 0x00002ae84626e25f in std::_Destroy_aux<false>::__destroy<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*>(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*) (__first=0x28e4190, __last=0x28e4198) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_construct.h:103
> #49 0x00002ae84626e1bd in std::_Destroy<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*>(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*) (__first=0x28e4190, __last=0x28e4198) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_construct.h:126
> #50 0x00002ae84626dce1 in std::_Destroy<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > >(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*, std::allocator<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > >&) (__first=0x28e4190, __last=0x28e4198) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_construct.h:151
> #51 0x00002ae846273bf3 in std::__cxx1998::vector<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >, std::allocator<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > > >::_M_erase_at_end(std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >*) (this=0x2633240, __pos=0x28e4190) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_vector.h:1352
> #52 0x00002ae846273b94 in std::__cxx1998::vector<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >, std::allocator<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > > >::clear() (this=0x2633240) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stl_vector.h:1126
> #53 0x00002ae846251d8c in std::__debug::vector<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> >, std::allocator<std::unique_ptr<chart::VCoordinateSystem, std::default_delete<chart::VCoordinateSystem> > > >::clear() (this=0x2633240) at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/debug/vector:563
> #54 0x00002ae84623749c in chart::ChartView::impl_deleteCoordinateSystems() (this=0x2633140) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:1136
> #55 0x00002ae846240346 in chart::ChartView::createShapes() (this=0x2633140) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:2484
> #56 0x00002ae84623d8f6 in chart::ChartView::impl_updateView(bool) (this=0x2633140, bCheckLockedCtrler=true) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:2563
> #57 0x00002ae846243eae in chart::ChartView::update() (this=0x2633140) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:2720
> #58 0x00002ae845bafef5 in chart::ChartController::execute_Paint(OutputDevice&, tools::Rectangle const&) (this=0x2a60ac0, rRenderContext=..., rRect=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/main/ChartController_Window.cxx:479
> #59 0x00002ae845bceb26 in chart::ChartWindow::Paint(OutputDevice&, tools::Rectangle const&) (this=0x2928e60, rRenderContext=..., rRect=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/main/ChartWindow.cxx:100
[...]
> #71 0x00002ae8280ee03c in Scheduler::ProcessTaskScheduling() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/source/app/scheduler.cxx:451
> #72 0x00002ae8280ed1ed in Scheduler::CallbackTaskScheduling() () at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/source/app/scheduler.cxx:270
> #73 0x00002ae828302716 in SalTimer::CallCallback() (this=0x20db780) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/inc/saltimer.hxx:55
> #74 0x00002ae828300b84 in SvpSalInstance::CheckTimeout(bool) (this=0x12640d0, bExecuteTimers=true) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/headless/svpinst.cxx:206
> #75 0x00002ae828301a61 in SvpSalInstance::DoYield(bool, bool) (this=0x12640d0, bWait=true, bHandleAllCurrentEvents=false) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/headless/svpinst.cxx:418
> #76 0x00002ae82811fbd1 in ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/vcl/source/app/svapp.cxx:471
[...]
> Thread 1 (Thread 0x2ae842779700 (LWP 13177)):
> #0 0x00002ae8461307dc in com::sun::star::uno::Reference<com::sun::star::chart2::XScaling>::set(com::sun::star::chart2::XScaling*) (this=0x2ae842776bb8, pInterface=0x9999999999999999) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/include/com/sun/star/uno/Reference.hxx:234
> #1 0x00002ae84612f8a0 in com::sun::star::uno::Reference<com::sun::star::chart2::XScaling>::operator=(com::sun::star::uno::Reference<com::sun::star::chart2::XScaling> const&) (this=0x2ae842776bb8, rRef=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/include/com/sun/star/uno/Reference.hxx:349
> #2 0x00002ae846140bea in chart::ExplicitScaleData::operator=(chart::ExplicitScaleData const&) (this=0x2ae842776b98) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/inc/chartview/ExplicitScaleValues.hxx:37
> #3 0x00002ae846171ad2 in chart::VCoordinateSystem::getExplicitScale(int, int) const (this=0x28c2b60, nDimensionIndex=1, nAxisIndex=0) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/axes/VCoordinateSystem.cxx:272
> #4 0x00002ae84623d475 in chart::ChartView::getExplicitValuesForAxis(com::sun::star::uno::Reference<com::sun::star::chart2::XAxis>, chart::ExplicitScaleData&, chart::ExplicitIncrementData&) (this=0x2633140, xAxis=..., rExplicitScale=..., rExplicitIncrement=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/view/main/ChartView.cxx:1735
> #5 0x00002ae845954d69 in chart::wrapper::Chart2ModelContact::getExplicitValuesForAxis(com::sun::star::uno::Reference<com::sun::star::chart2::XAxis> const&, chart::ExplicitScaleData&, chart::ExplicitIncrementData&) (this=0x26b6920, xAxis=..., rOutExplicitScale=..., rOutExplicitIncrement=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/chartapiwrapper/Chart2ModelContact.cxx:143
> #6 0x00002ae8459d1d20 in chart::wrapper::WrappedScaleProperty::getPropertyValue(chart::wrapper::WrappedScaleProperty::tScaleProperty, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) const (this=0x2b68480, eScaleProperty=chart::wrapper::WrappedScaleProperty::SCALE_PROP_STEPMAIN, xInnerPropertySet=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/chartapiwrapper/WrappedScaleProperty.cxx:389
> #7 0x00002ae8459d114b in chart::wrapper::WrappedScaleProperty::setPropertyValue(chart::wrapper::WrappedScaleProperty::tScaleProperty, com::sun::star::uno::Any const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) const (this=0x2b68480, eScaleProperty=chart::wrapper::WrappedScaleProperty::SCALE_PROP_AUTO_STEPMAIN, rOuterValue=..., xInnerPropertySet=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/chartapiwrapper/WrappedScaleProperty.cxx:234
> #8 0x00002ae8459d0893 in chart::wrapper::WrappedScaleProperty::setPropertyValue(com::sun::star::uno::Any const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) const (this=0x2b68480, rOuterValue=..., xInnerPropertySet=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/controller/chartapiwrapper/WrappedScaleProperty.cxx:130
> #9 0x00002ae846523605 in chart::WrappedPropertySet::setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) (this=0x2b64cc0, rPropertyName=..., rValue=...) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/chart2/source/tools/WrappedPropertySet.cxx:89
> #10 0x00002ae841d97854 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) (pThis=0x2b64cf8, nVtableIndex=4, pRegisterReturn=0x0, pReturnTypeRef=0x127fb10, bSimpleReturn=true, pStack=0x2ae8427777d0, nStack=0, pGPR=0x2ae842777ae0, pFPR=0x2ae842777aa0) at /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:77
[...]
Change-Id: Id0236bf04bff9f06f8fc5ee9e2db295216a54c16
Reviewed-on: https://gerrit.libreoffice.org/60474
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1637696282df596e9e86d65739f77904b89b6f51
Reviewed-on: https://gerrit.libreoffice.org/60436
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8744b5c4d6f97b88f09d8c2455be0407c75c9b79
Reviewed-on: https://gerrit.libreoffice.org/60435
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
no need to re-init this every time we look up a color
Change-Id: I68113fc6a36880752f5eb7813df1f0d971678013
Reviewed-on: https://gerrit.libreoffice.org/60493
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Keeping a function active after a subsequent click only makes sense
for shape drawing, as it's used to lock the function so more that one
shape can be drawn in a row. Otherwise just do what users expect, and
turn the function off.
Affected commands:
.uno:Mirror
.uno:Crop
.uno:InteractiveTransparence
.uno:InteractiveGradient
.uno:Shear
.uno:CrookRotate
.uno:CrookSlant
.uno:CrookStretch
.uno:ConvertInto3DLathe
.uno:ZoomMode
.uno:ZoomPanning
Change-Id: Ic441cd72423cbc0570c4a070402b474e85b5084b
Reviewed-on: https://gerrit.libreoffice.org/60472
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Tested-by: Heiko Tietze <tietze.heiko@gmail.com>
|
|
Change-Id: Ice7c211b10d59ab9d166da6e09662b602debb09d
Reviewed-on: https://gerrit.libreoffice.org/60417
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
otherwise the GtkImage's width isn't right
Change-Id: Id5e44749fb9925037d5777512e3123de8840d346
Reviewed-on: https://gerrit.libreoffice.org/60484
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
It can be useful.
This reverts commit b140f92531396c1087b997852d7ece18429b79d1.
|
|
Change-Id: Ie4436986f847828cf1644325d692d64c344b03c5
Reviewed-on: https://gerrit.libreoffice.org/60482
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
regression from
commit 510033783a9921eef507d424fc5adf6e2696bc4a
loplugin:useuniqueptr in ScHTMLLayoutParser
Change-Id: If2c46552d8c784eb2ea1b182140fd731c39b1bd3
Reviewed-on: https://gerrit.libreoffice.org/60483
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia54a5ac4fe4a11b7c03508c336193bb52c616e7f
|
|
Change-Id: Ia5016284c338f5d305d9f7fc92180a770230b446
Reviewed-on: https://gerrit.libreoffice.org/60479
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Only write to 'pFakeArgv[2]' when 'aDisplay' is NON-empty.
Otherwise, the 'pFakeArgv' array only has size 2 and the write
is invalid.
(Found by valgrind while looking at another issue.)
Change-Id: I58aff6d25c8647bc6ef346af8ac09b0b0fc030b8
Reviewed-on: https://gerrit.libreoffice.org/60476
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Change-Id: I1072642be4fdfa720e61f2d7bad3c2701eb81610
Reviewed-on: https://gerrit.libreoffice.org/60430
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib5a02c71fa66f46a8e1072c5c0a263e1eb977692
Reviewed-on: https://gerrit.libreoffice.org/60454
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9ab88f5d15a2d98285ac4c1ffce8750c16830d56
Reviewed-on: https://gerrit.libreoffice.org/60453
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
to make the handling more explicit here
Change-Id: I934fcc7b0da8a160acd904440f18fc6c01ec1ad3
Reviewed-on: https://gerrit.libreoffice.org/60475
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie01de0c9463b9a1012d4b1adc9e92e8f8b1d8a58
Reviewed-on: https://gerrit.libreoffice.org/60447
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0a64d0eb9938d5a99416dbe4078ba4c05e5d588b
Reviewed-on: https://gerrit.libreoffice.org/60465
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
when it has no other paragraph property change.
Change-Id: I4e18c89f1a4c7f39a7e55303956b85f61c9d5105
Reviewed-on: https://gerrit.libreoffice.org/60442
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: If929ee4725f65d8695367f38b5203be3a7e426d1
Reviewed-on: https://gerrit.libreoffice.org/60457
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I524375af95b988e53838b87c00be5fbaf2895a84
Reviewed-on: https://gerrit.libreoffice.org/60456
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5cc13b33f46eee9a770049c1127e5de47fecea84
Reviewed-on: https://gerrit.libreoffice.org/60455
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I068c83db5a3f5e717c72e4f2459a18eee690bbfd
Reviewed-on: https://gerrit.libreoffice.org/60452
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I76647a9441fee2f4d2d338a70f9bf95e80fa18ee
Reviewed-on: https://gerrit.libreoffice.org/60451
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I34fac0560a1a408df421365379b15e64c96c9a15
Reviewed-on: https://gerrit.libreoffice.org/60450
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...introduced with fec05c3deabec6299eec87fa481b7e50b6fb29f5 "#90279#
performance: DoSubTotals: collect formula cell positions and put cells after
InsertRow calls to not have them inspected for updates again" and hopefully no
longer necessary
Change-Id: I2cd781c81defb3838612d460e8234fd4de97b88d
Reviewed-on: https://gerrit.libreoffice.org/60459
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia888dba63ee6917bd5726e92a8e248b63f744047
Reviewed-on: https://gerrit.libreoffice.org/60467
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Inherited from OOo, these insideV/H borders incorrectly assume
that every inside border will match the bottom/right border
of cell A1. For the most part this error is harmless since
every cell specifies every border anyway (that doesn't match
a table-style default). The only time it is visible is when
insideV/H specifies a border, but none is set on the cell.
The problem is that these pseudo-defaults are not passed
to the cellborders function as defaults, so cells have no idea
whether they need to override these values or not.
Since the implementation is completely flawed and unnecessary,
simply eliminate it.
(TODO: In fact, the entire tblBorders output is flawed,
as demonstrated by the outside borders in the unit test.)
One unit test is removed since insideV/H is no longer
being written (this was just a "lets specify what we
see being written out" test, not one concerned specifically
with insideV/H. Not enforcing the absence of insideV/H because
theoretically someone could legitimately add zero-width
borders to the table borders and still be valid.
The ordering of the borders test was moved from a
table borders test (no longer created) to a styles
border (which is still valid - a grabbag dump.)
Change-Id: Ie6786a66fe88d2c7e3bdcff8fda3b4f77cb988d7
Reviewed-on: https://gerrit.libreoffice.org/59675
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
This is effectively dead code as commit
547217ecf2348cf511b1f058ecbab6f15f2bceff (Document seemingly dead
QuickDiagrammingImport, QuickDiagrammingLayout, 2013-06-03) found, so
the primary motivation is to just get this out of
oox_component_getFactory().
Change-Id: If0a585c2fc4b87ceb00e6f772fef2ac65d10dc67
Reviewed-on: https://gerrit.libreoffice.org/60470
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|