In SdrPaintView (and subclasses) the mpModel variable is always
the same as the input (reference) model, so there is no need for
that extra variable.
Change the strange and confusing var. name mrSdrModelFromSdrView
(the input reference to SdrModel) to just mrModel and use that in
GetModel(). Change the GetModel() to return a reference instead
of a pointer and reactor the code to accomodate the change.
This gets rid of many nullptr checks for the pointer that the
GetModel() returns and makes the code more simple is some cases.
Change-Id: I18351a417fd82f49262a83de036ec1420a65399c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146373
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: Ib681b4eaa44c65b9da5988c74c03f1829e3a1507
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144334
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Both sfx2::XmlDump and css::qa::XDumper were (only) used to dump various data
from ChartModel and ChartView instances in debugging (e.g., F12 and Shift-F12 in
an SW_DEBUG=1 Writer) and testing scenarios. The problem with XmlDump was that
it was used as the target of a dynamic_cast from a UNO type, which is dangerous
(see the upcoming commit introducing loplugin:unocast for details). One fix
would have been to replace that dynamic_cast with a use of XUnoTunnel, and make
ChartModel and ChartView implement that. But those classes already implement
XDumper, so it looks more natural to use XDumper for that purpose too.
However, the information that was obtained via XDumper was rather different from
the information that was obtained via XmlDump. So make an incompatible change
to the (unpublished) XDumper, adding a kind parameter distinguishing the
original behavior of XDumper (kind == "shapes") from the original behavior of
XmlDump (kind == "").
Change-Id: Ia7379bedfc45ab62a298fdc2f030cebaf21c4885
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144145
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
As mentioned in commit 510bca3d3ab0b2fd21f0083b4e0fe14ff8c903c3,
over the time these functions were changed; now they don't take
logical coordinates, but pixels, so became true duplicates of
corresponding Mouse* functions.
The calls to SetLastMousePos are now made from LOKPostAsyncEvent
uniformly.
Change-Id: I2c8a9095719c0c8e21cf81342a286b00c1d1a41c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141693
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
to reproduce this in reality, insert a chart, activate it, select and
copy and paste something like a bar of a bar chart. Select that copy and
copy to clipboard again. reactivate chart, paste that element into the
surrounding spreadsheet, select and copy something else to clear the
chart transferrable and the model created by the chart transferrable
leaks.
there are an unrelated blizzard of a11y mutex deadlocks here btw :-(
Change-Id: I650885d8c784cc1b2b023af8f5e23b3dceb2d9f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139794
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Which means we can get rid of the majestic hack of ScCaptionPtr
Previously, SdrObject was manually managed, and the ownership
passed around in very complicated fashion.
Notes:
(*) SvxShape has a strong reference to SdrObject, where
previously it had a weak reference. It is now strong
since otherwise the SdrObject will go away very eagerly.
(*) SdrObject still has a weak reference to SvxShape
(*) In the existing places that an SdrObject is being
deleted, we now just clear the reference
(*) instead of SwVirtFlyDrawObj removing itself from the
page that contains inside it's destructor, make the call site
do the removing from the page.
(*) Needed to take the SolarMutex in UndoManagerHelper_Impl::impl_clear
because this can be called from UNO (e.g. sfx2_complex JUnit test)
and the SdrObjects need the SolarMutex when destructing.
(*) handle a tricky situation with SwDrawVirtObj in the SwDrawModel
destructor because the existing code wants mpDrawObj in
SwAnchoredObject to be sometimes owning, sometimes not, which
results in a cycle with the new code.
Change-Id: I4d79df1660e386388e5d51030653755bca02a163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138837
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This adds a new object type "Data Table", with all the object
identifiers and converters of properties.
The data table is now shown in the drop-down of chart elements.
A properties dialog was added, which allows to change properties
of a data table. This contains the area, line and font tab pages
and a new tab page specific for data tables, to change if the
horiz. or vert. borders, key or the outline should be show.
Change-Id: I9b4cd58cffbcc952daaa2c0c8f8a5a17e38ac293
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138246
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
make the plugin more conservative, so we see less false+
(although we also miss some possibilities in the process)
Change-Id: I91b1806271e7f802d7459834ab7bcc569047da3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137342
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
By default Rectangle uses closed interval, if we really want to use half
open intervals then we should specifically say as such in the name.
Change-Id: Id7a91120ba1a1a4bc330014216b73a692dbf03a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136575
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
If we are not going to manipulate the resulting vector, then it is
actually slower, since we have to allocate more storage for the vector
Change-Id: I65677007d105f4783603df74113ebed6db0b551b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133963
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
See tdf#42949 for motivation
This time using the new --noexclude switch to recheck validity
of the excludelist; these were the obsolete exclusions
Change-Id: Ifdf79b30ebaf198082c2194611a2ed2b664e6f1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133309
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Introduced in commit 2d01ed9e8b
Author Muhammet Kara <muhammet.kara@collabora.com>
Date Mon Nov 25 21:55:31 2019 +0300
tdf#94288: Show chart props sidebar on activation
The problem was that ChartController::attachFrame, that called
SelectionChangeHandler::selectionChanged notification, did that
*prior* to setting its m_xFrame - and the notification failed
in ContextChangeEventMultiplexer::NotifyContextChange, that
checks the frame first. That prevented the proper context (with
correct application and context names) to arrive to listeners,
and the sidebar didn't update properly.
Changing the order of the calls should fix the original problem.
Change-Id: I9da8465af2ee4ed1f8eabed1c65d1c318f81a3f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133326
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tomaž Vajngerl