- Add new text Glow effect properties for shapes
- Using TextGlowPrimitive for rendering uniform text glow in shapes
- Add/allow new UI Glow Effect for texts in shapes on sidebar
(Only for Impress/Draw and Calc)
- Import/Export ooxml files with Glow effect on texts in shapes
(Only PPTX/XLSX)
- Import/Export odf files with Glow effect on texts in shapes
- Add unit test for glow text attributes in ODF
- Add uni tests for OOXML import/export
Note: Also this patch effects on
tdf#144061 - Effects: Allow GLOW to apply to Text (as we have for shapes)
Change-Id: I16586c01654f197f532129e4e06aa2ef9f214395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172216
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
which simplifies the hierarhcy.
We never allocate such a thing, we always allocate subclasses, and it
has no real meaning by itself.
Change-Id: Ie6b716c9ea6ca0efe0ae4f39ac345608c45534f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
with clang version 17.0.6 on openSUSE 15.6 we seem to be getting a crash
here (originally reported to me by mmeeks)
Change-Id: I7b0b1b986a7f66af988e58d4fec019b9e29a64da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171754
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I ran into a problem where this global object would be destroyed and
then resurrected during shutdown.
Rather than make the existing code more complex, extend the existing
vcl::DeleteOnDeinit code and re-use that here.
Change-Id: Ib63739f57f489b1131111e9bab1db5fba7fd17bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169697
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
> In file included from libreofficekit/source/gtk/lokdocview.cxx:26:
> In file included from include/vcl/event.hxx:28:
> In file included from include/vcl/outdev.hxx:30:
> In file included from include/vcl/bitmap.hxx:31:
> In file included from include/vcl/region.hxx:26:
> In file included from include/basegfx/polygon/b2dpolypolygon.hxx:27:
> In file included from include/basegfx/range/b2drange.hxx:27:
> In file included from include/basegfx/point/b2dpoint.hxx:27:
> include/basegfx/tuple/Size2D.hxx:30:10: error: this member function can be declared static [loplugin:staticmethods]
> 30 | TYPE getWidth() const { return Tuple2D<TYPE>::getX(); }
> | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/basegfx/tuple/Size2D.hxx:32:10: error: this member function can be declared static [loplugin:staticmethods]
> 32 | TYPE getHeight() const { return Tuple2D<TYPE>::getY(); }
> | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/basegfx/tuple/Size2D.hxx:34:10: error: this member function can be declared static [loplugin:staticmethods]
> 34 | void setWidth(TYPE const& rWidth) { Tuple2D<TYPE>::setX(rWidth); }
> | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/basegfx/tuple/Size2D.hxx:36:10: error: this member function can be declared static [loplugin:staticmethods]
> 36 | void setHeight(TYPE const& rHeight) { Tuple2D<TYPE>::setY(rHeight); }
> | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...but no idea why exactly that started to hit me just now
Change-Id: Ibb2b57b54b07461a50375ee64670ff21e4670b8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168082
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(*) remove some debugging code
(*) loosen constraints a little so I can see if there are more
interesting opportunities
(*) rename some local vars to make it read better
(*) strip const/& modifiers from types before comparing
(*) ignore vars/fields that are references, they do indicate that a
class was instantiated
Change-Id: I66014b8f0aa24c2e3ca34af75b75e6cd6c939ea6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167383
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
and adjust the loplugin:stringstatic to cope with OUString that
is also declared in a header as extern, in which case we cannot
mark it as constexpr.
Change-Id: I108aa3ff8cb06a9a6d345cd951883b52dd0318f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167106
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Also the key path was wrong in SlsCacheConfiguration.cxx:
MultiPaneGUI/SlideSorter/PreviewCache
but in Impress.xcs we have
MultiPaneGUI/SlideSorterBar/PreviewCache
hierarchy so this may actually now start to work :)
Change-Id: I4b552be713e6e157edb45692ba78101429aa1c85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166755
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
writerfilter wants to convert incoming RTF and OOXML files into
writer's document model. But it currently has to do so by
manipulating the limited subset that we expose through the UNO
API.
This is both slower and less accurate than having access
to the full document model.
So move it inside, and then we can strip out various hacks, and
optimise imports.
Change-Id: Ie1114d28130ef5f9a786531bc552cb8ee7768015
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165953
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
create a plugin that finds methods we can mark as final because they are
not override in subclasses.
Which is useful both as documentation (telling you that you don't need
to worry about subclasses changing the implementation under you),
and for performance, letting the compiler elide virtual calls in many
cases.
Apply the results to a subset of stuff in /include
Change-Id: I7b5cc893ec2f343bc356bfc338e4cf531ffba1e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165054
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Some of the exclusions were too aggressive. Restrict them to only the
important classes, which exposes some more places this plugin applies.
Change-Id: I1b2d1fb24391adc71ed0984f94168f61a149479f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165154
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The "final" was removed in commit
e06f2bb00137655dbf6f0a8c8c2fc555720f4d3f (tdf#142467 crash on calling
'getInfoHelper' in final class, 2021-05-26)
and commit
6cb1745c24 (tdf#142467: Update comments
with GCC bug ID, 2021-05-31)
due to a bug in gcc <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797>.
Now it has been amost 3 years past and that gcc bug has long been fixed,
so it is time to restore the "final".
Change-Id: I7db9fe59209cfbae4c04bb3a91cd764db9a38d98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163447
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Our main problem is how to compute the correct output area for the
requested tile zoom level. The old solution was using a fine-tuned
edit rectangle as output area. An edit rectangle is the rectangle
computed according to the range of rows and columns involved in the
text editing. Unfortunately in some cases the edit rectangle can be
enough larger than the output area. For instance that occurs with
centered text.
The new proposed solution is able to scale the output area to the
requested tile zoom level by a few pixels (0 up to 3) offset/size
error. The hope is to reduce the error in some follow-up patch.
The new solution is also able to perform painting of text edited by
different views in the correct order. The last painted text is the one
belonging to the last view where editing occurred.
SfxViewShell::maEditViewHistory keeps track of the last 10 editing
events per document.
Change-Id: I8f1035a730cb2b94b0990f3c8eb6445511b94223
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162196
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163031
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
...so recent LLVM 19 trunk libc++ in debug mode complained during
CppunitTest_chart2_export2 about
> ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering
at
> 5 libsystem_c.dylib 0x0000000183279a40 abort + 180
> 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0
> 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960
> 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268
> 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68
> 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508
> 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528
> 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440
> 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728
> 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692
> 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288
But the introduced use of `std::strong_order(first[0], second[0]) < 0` then
triggered a false
> lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr]
> 105 | return std::strong_order(first[0], second[0]) < 0;
> | ^
so needed some hack in loplugin:nullptr.
And old versions of libc++, still used at least on Android, do not have any
implementations of std::strong_order. So detect those cases in configure.ac
(checking for std::strong_order for double, which is what is actually being used
in the code) and fall back to operator <=> for now, even if that will not
provide a strict weak ordering and will thus continue to violate the
requirements of std::sort.
And then our venerable clang-format 5.0.0 would have broken the token `<=>` into
`<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment.
Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
NotebookBarViewManager is a singleton which is responsible to hold
NotebookBar view specific data, which is kept in NotebookBarViewData
class. The idea is to have one NotebookBarViewData class instance
per one view (SfxViewShell instance).
This also refactors the existing code and now moves the
m_pWeldedWrapper, m_pNotebookBar and the m_pToolbarUnoDispatcher
into NotebookBarViewData class.
Change-Id: I32f5954fa9f1628acd9f5f9bd5760ac23ca687ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162706
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Noel Grandin