Turns out the 2nd part of tdf#92768 was not implemented yet, so it is
still necessary to remove the title/subtitle for good, otherwise we set
the "Visibility" property, but nothing actually reads that when
rendering.
So the titles now work as they did before the regression. An uncheck action
removes the title/subtitle, and a check action just makes the existing
title/subtitle visible or creates a new one if it doesn't exist
Change-Id: I23122d1be2d95af878b824ba194bd1aeed5f4f89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90692
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105737
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
...to "Find functions that take rtl::O[U]String parameters that can be
generalized to take std::[u16]string_view instead." (Which in turn can avoid
costly O[U]String constructions, see e.g. loplugin:stringview and subView.)
Some of those functions' call sites, passing plain char string literals, needed
to be adapted when converting them.
Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
with unique values so that, e.g.
if (pObj->GetObjIdentifier() == OBJ_LINE)
is only true if pObj is a SdrPathObj and not a E3dScene
Change-Id: I30c91e57eb27141390c644dec42e2a4bee96edf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105374
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
move IsShowOutlineContentVisibilityButton out of header to
avoid having to add extra include paths to all the unit
test makefiles.
Change-Id: I2763390e07cd85b8f09b6f2ad7702039daecb22f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105100
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
in places where it is obvious we only need a sal_Int32, because
we are dealing with rows and columns, and not even calc needs
more than 32 bits for that.
Change-Id: I114417e639c224d45bfd9fc6838122ab195eefa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104584
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Prevent us from crash in online using mobile phone
when leaving chart edit mode with chart type modified.
Change-Id: I8da70612786141a2c92b55a45822ef8ff5713e5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104606
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
The default font size of text in shapes is 12pt in LibreOffice,
nevertheless, we used 24 pt for font size in custom shapes inside
chart objects during ooxml import.
Change-Id: I69d02374bc4b4781e2ca617913c642999b3d5fa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104429
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Reviewed-by: László Németh <nemeth@numbertext.org>
gtk is creating a11y objects on widgets changing parents so manage when that
can happen to avoid premature creation of custom widget a11y objects
Change-Id: I4879a93a897b2e4084cf6af0c9c0b0f0c1062254
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104025
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This renames AntialiasingFlags::EnableB2dDraw to just Enable,
and the AntiAliasB2DDraw names to just AntiAlias. This is
in preparation for a second commit that will actually separate
the AA and B2D functionality of these flags.
Change-Id: I9cc215c5752dfabce41e00e19d9074fc8dc3d4de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103416
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
There is no similar setting in MSO, it just always uses clockwise.
LO on the other hand confuses users by using counterclockwise
which turns to clockwise upon save to OOXML and reload.
Eliminate this behavior by introducing a compatibility key
for OOXML-heavy environments that:
- sets the orientation to clockwise when pie chart type is selected
- hides the checkbox that would have no effect after a save to OOXML
Default value is false to keep current behavior
Change-Id: I9e12ecad8e9978f960c921a521461aee023a5063
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/82524
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: Balazs Varga <balazs.varga991@gmail.com>
Reviewed-by: László Németh <nemeth@numbertext.org>
Now Delete Data Labels and Insert Data Labels local
menu options remove custom label text instead of keeping it.
See with unit test document custom_data_label.xlsx of
commit bcda268cde
(tdf#134977 Chart OOXML: fix import of custom data label).
Change-Id: Ifc7afd0f2ece9da528e6206a6bd393b394b36f9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101929
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
to avoid chart distortion.
Set the maximum text width of data point label shape based
to the 80% of the remaining space, when text wrapping is enabled
and the label placement is AVOID_OVERLAP.
Change-Id: I174089ec62df3aa21b5d1f26f74d475945d83684
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102744
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
do more like
commit 121771e37f
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
because InternalDataProvider can not handle different category names
on the primary and secondary category axis.
Revert e0b0502516 commit, except
the relevant unit test.
Regression from commit: e0b0502516
(tdf#128016 Chart OOXML Import: fix duplicated category labels)
Also fix tdf#129994 (FILEOPEN - hang at import time), which is a
a regression from commit fa0a981af4
(tdf#114166 DOCX chart import: fix missing complex categories)
Change-Id: I5d049e760eb1a647ea774be264349a2f16f15f5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102463
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
gtk will expand to fit all children, while vcl will clip.
insert a borderless ScrolledWindow with "external" scrolling
to allow the dialog to clip the children (same thing we do
for our menubar to shrink down past its natural size)
adjust the width calculation to avoid logictopixel rounding
Change-Id: Id2e4f92959f1827c6960360d1530a9c63a4d0c00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102972
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
between data points and displaced data labels of a data series.
Follow-up of the following commits related to the new UNO property
ShowCustomLeaderLines for data labels:
commit e2f4e65a7b
(tdf#134571 chart2, xmloff: add loext:custom-leader-lines)
commit 5d67d70b26
(tdf#134563 Add UNO API for custom leader lines)
Change-Id: Id8a953b16ff737ca924c0c2c3241fba4e3ac904b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102221
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Regression from commit bb97ecdbcc,
which had dropped storing chart doc (calling its storeOwn) while
loading back in 2012, to avoid performance problems when loading
XLS.
Funnily, in 2013, commit a666862def
was merged, that was expected to solve exactly the same problem as
this change, by calling storeOwn for charts being loaded; while
obviously not fixing the problem properly, it seems to had undone
the effect of the Markus's commit.
The latter commit had a side effect of updating views of modified
charts while exporting them inside storeOwn, which made respective
draw pages to be up-to-date right after loading, including those on
inactive sheets. Now, after this change, this is not so, thus unit
tests' getChartDocFromSheet was made to update the view explicitly.
Unfortunately, it's not yet possible to revert the change from
commit a666862def, because obviously
some dependency grew, which makes e.g. testTdf122594 fail if that
commit is reverted. Given that testTdf122594 has no charts, storing
the modified objects while loading has much wider side effects than
was expected by author of a666862def.
Change-Id: Iee1b9ef6f4d8c2dfa0a49680c5e2b465f1817a59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102534
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Andrea Gelmini