Age | Commit message (Collapse) | Author |
|
Now complex category labels are visible, and the inner data
table contains the correct texts of the category columns.
Note: repeating call of createDataSequenceByValueArray() API function
can create all columns of the complex categories. See also
commit 6c4e21a234f12e1310ba06f9859e08b424acf8bf
"bnc#812796: Correctly handle static value array for OOXML charts."
Change-Id: I333b79be35a24a912bb9e662116d0c85809a8fb2
Reviewed-on: https://gerrit.libreoffice.org/75776
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
this is combination of
commit dd15e149326f5270ab9ceb5f21e32b25b96c0a44
Author: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Date: Sun Nov 11 23:37:24 2018 -0500
LOK: sd: initialize slide-sorter in sd
(Change-Id: I4cb6ce6d961b4ba4d542c14cb37370788cf75e45)
and
commit 7e291eedbad335bf8bbc8a17cc3d633bf66d0e90
Author: Jan Holesovsky <kendy@collabora.com>
Date: Thu Apr 25 05:54:15 2019 +0200
(Change-Id: I86b23b484674ad4c6a75246ee6186ad9b828931f)
sd lok: Remove the .uno:LeftPaneImpress call from sd lok initialization.
According to my testing, this makes no difference and the moving of
slides and multiple selection behaves the same way with or without this.
So let's return to not activating the SlideSorterBar, because otherwise
we are doing a lot of pixel bashing behind the scenes unnecessarily.
Having said that, if we want to activate it at some stage, it is better
to do something like the following (+ remove the explicit LOK-only if's
from svtools/source/config/slidesorterbaropt.cxx):
SvtSlideSorterBarOptions().SetVisibleImpressView(true);
instead (and potentially we can also make it floating not to occupy the
space in the main view by
GetWindow()->SetFloatingMode(true);
in the LOK case in sd/source/ui/dlg/PaneChildWindows.cxxi).
Change-Id: I719bc4ca5e43fce9949d494149b65ffd8587c601
Reviewed-on: https://gerrit.libreoffice.org/76220
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I87f59593d7a1691d07276421aaa501751b4953e5
Reviewed-on: https://gerrit.libreoffice.org/76226
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia1b3137916ae37ed73ac9923af847aa15978dc86
Reviewed-on: https://gerrit.libreoffice.org/76228
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I10ec0bbaab2bc38b67c4a2a557c33f1a4ed2ddfc
Reviewed-on: https://gerrit.libreoffice.org/76223
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibb904fc1c5d283d8ca9d8ff8b2249d25d7091b5b
Reviewed-on: https://gerrit.libreoffice.org/75954
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
|
|
Change-Id: I7bf7a428d53b7a1a4e0675414c4532f1f5b763a9
|
|
This might lead to confusion as if there were different macro types depending on the current downstream package name. E.g. "LibreOffice Basic macros" might become "LibreOffice Vendor XY basic macros".
Remove that confusion by using just "Basic macro" in the UI.
Change-Id: Ifc2543bb151e94fc6c6e47d878720dd99294f596
Reviewed-on: https://gerrit.libreoffice.org/76216
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: Ibe9ee3d5f555d153fd208a03ba2e3ae68d263ab3
Reviewed-on: https://gerrit.libreoffice.org/76224
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I485efe5fae00c8ddfb250f5f794d789f91816d6b
|
|
Partial revert of:
https://gerrit.libreoffice.org/#/c/76028/4
Change-Id: I94173556f1dff21ff47245f8b632411fc8be1ff6
Reviewed-on: https://gerrit.libreoffice.org/76200
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
(std::malloc, std::realloc)
Change-Id: I0861b99adb841a323ceeeaf56b964ab7d669b48a
Reviewed-on: https://gerrit.libreoffice.org/76217
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7f436983ba0eb4b76b02d08ee52626e54b103d5f
Reviewed-on: https://gerrit.libreoffice.org/76189
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
in drawAlphaRect so the rect path is set after the matrix
Change-Id: I3ded9383f6f16f77902c5ad576e520f37326e8af
Reviewed-on: https://gerrit.libreoffice.org/76199
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
cairo_set_matrix doesn't appear to have any effect on an existing path,
so set a new path on both fill and stroke so the matrix set for line
will have an effect, so drop cairo_fill_preserve to cairo_fill and
rely on the path cache.
Change-Id: I31f16b094c920b107467a9492c7194bb578c1924
Reviewed-on: https://gerrit.libreoffice.org/76198
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
this change should have no visual effect
Change-Id: Id93519e6b74e2c9bc4ddf20e7ab903689d7d8ee3
Reviewed-on: https://gerrit.libreoffice.org/76197
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
we're calling cairo_fill_preserve so we can reuse the same
path to stroke. We don't use this path again after stroke.
this change should have no visual effect
Change-Id: I1ad6af875b0a58a0699b5d9801c76510cc242ab9
Reviewed-on: https://gerrit.libreoffice.org/76196
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9991a1f4d8dde51b38cf8d114e4fb69ff4a349ea
Reviewed-on: https://gerrit.libreoffice.org/75248
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I4089dbe19f54d7707a8832886b9c97a72bc80751
Reviewed-on: https://gerrit.libreoffice.org/75116
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The misleading indentation made me waste some time till I realized that
the affected lines are not executed unconditionally inside the function.
Change-Id: Ie6ffd1866ca2e1b6fd49814f703960c2d6641395
Reviewed-on: https://gerrit.libreoffice.org/76208
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ia095c30e6ca4e7b9d6ba0dcf5b796353bfd088be
Reviewed-on: https://gerrit.libreoffice.org/75559
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: I1c67cde8401106a7e9d7ecd5fd3e0b4925ab47d4
Reviewed-on: https://gerrit.libreoffice.org/76212
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ieac1a0acb97664f3b86e2524cab79fd278f42e0e
Reviewed-on: https://gerrit.libreoffice.org/76210
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Remove lambda and one extra begin() call.
6ffdc88e79904882e319bdd0b901e7491abae0b3 follow-up
Change-Id: Ieb427704112f4d52c044147a5162921448f0590d
Reviewed-on: https://gerrit.libreoffice.org/76205
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
It passed "make check"
Change-Id: I055017a7616ed4d9725c66a387c040b55e22751f
Reviewed-on: https://gerrit.libreoffice.org/76202
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: Iea3bd498b1c8934f37085bdf6df71b073e4a871c
Reviewed-on: https://gerrit.libreoffice.org/76203
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Change-Id: I4ea9c274c1f3548f132ead290efefc1a7972e5c7
Reviewed-on: https://gerrit.libreoffice.org/76152
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1881e2c8cdccf9c020ed52d2e90689e6a02791b5
Reviewed-on: https://gerrit.libreoffice.org/75561
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
most of this stuff is unused, and we only ever have one image-list
Change-Id: I2c7aba4b537b725a627df65609167aea3159553e
Reviewed-on: https://gerrit.libreoffice.org/76148
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
by keeping paragraph-level ParagraphFormat redlines.
(regression from commit a5abe0fc4d435d3a7a7de8bf55ec74087fdd299a
"tdf#125546 DOCX import: fix overgrowth of change tracking entries")
Change-Id: I1357a9e082f990c8a7d1d1aa6f93a06c3dfee5a8
Reviewed-on: https://gerrit.libreoffice.org/76154
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
back in 5-4 series FWIW, since...
commit a3c95ec45397b146c86a3fa44445c763de99d3a3
Author: Caolán McNamara <caolanm@redhat.com>
Date: Mon Jun 11 09:00:46 2018 +0100
rhbz#1589029 tdf#93789 impress not showing text highlight in presentation mode
Change-Id: I8412854cd32af73cf2512db8c424d56ed84d9c1e
Reviewed-on: https://gerrit.libreoffice.org/76153
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...by clamping the value to the sal_Int32 range. An alternative would be to
instead print nAdjustment as a real value (which the PDF standard apparently
supports, without giving limits to such real values), as had been implemented at
<https://gerrit.libreoffice.org/#/c/74543/1>, but that was deemed unnecessarily
complex, as no sane document should require nAdjustment values outside the
sal_Int32 range.
`--convert-to pdf caolan/drawinglayer_emfphelperdata_heap_use_after_free.sample`
(from the crashtestdata files) has cases where
double fAdvance = aThisPos.X() - aPrevPos.X();
gets rather large (whether or not that's faithful to the input document, or a
consequence of an earlier import error), so failed with
> vcl/source/gdi/pdfwriter_impl.cxx:6078:66: runtime error: -5.83192e+09 is outside the range of representable values of type 'int'
> #0 in vcl::PDFWriterImpl::drawHorizontalGlyphs(std::__debug::vector<vcl::PDFWriterImpl::PDFGlyph, std::allocator<vcl::PDFWriterImpl::PDFGlyph> > const&, rtl::OStringBuffer&, Point const&, bool, double, double, double, int, int) at vcl/source/gdi/pdfwriter_impl.cxx:6078:66
> #1 in vcl::PDFWriterImpl::drawLayout(SalLayout&, rtl::OUString const&, bool) at vcl/source/gdi/pdfwriter_impl.cxx:6404:17
> #2 in vcl::PDFWriterImpl::drawTextArray(Point const&, rtl::OUString const&, long const*, int, int) at vcl/source/gdi/pdfwriter_impl.cxx:6621:9
> #3 in vcl::PDFWriter::DrawTextArray(Point const&, rtl::OUString const&, long const*, int, int) at vcl/source/gdi/pdfwriter.cxx:87:22
> #4 in vcl::PDFWriterImpl::playMetafile(GDIMetaFile const&, vcl::PDFExtOutDevData*, vcl::PDFWriter::PlayMetafileContext const&, VirtualDevice*) at vcl/source/gdi/pdfwriter_impl2.cxx:878:34
[...]
In the original compuation of sal_Int32 nAdjustment, the "+ 0.5" was presumably
intended to round to the nearest integer, even though it would have rounded
towards zero for negative values (as conversion to integer truncates). So use
std::round to always round to the nearest integer, including for negative
values.
Change-Id: Ie3ddbb66421f47417c6d9ae096f2207a29aca4a4
Reviewed-on: https://gerrit.libreoffice.org/74543
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
... see https://gerrit.libreoffice.org/72417
They will be drawn client-side. Borders and explicit cell background are
still drawn in core. This mode is activated using "sc_no_grid_bg" option
in SAL_LOK_OPTIONS environment variable.
Change-Id: Ie10e7770b8168ec648d44ae5af0a0a0602d89ee6
Reviewed-on: https://gerrit.libreoffice.org/75484
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
if not bFirst, then it is more efficient
to start the search from the end.
Change-Id: I89bcb3b70ada7746ab983878f2868f58b89f37a5
Signed-off-by: Adrien Ollier <adr.ollier@hotmail.fr>
Reviewed-on: https://gerrit.libreoffice.org/76126
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
various bits are no longer used since
commit ca00697e3dae9a03573d11281fc8d9a4ee391d3d
Date: Tue Sep 8 04:57:32 2009 +0000
CWS-TOOLING: integrate CWS oj18
Change-Id: Iea57cee35026fd90f6a9aaf9927a80a646d722bb
Reviewed-on: https://gerrit.libreoffice.org/76147
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
New IWYU and recent developments in f-u-i helped to identify
some non self contained files, those were fixed too.
Change-Id: I527f7c2cf2660a758b13eabb4c444ff79ae35f8c
Reviewed-on: https://gerrit.libreoffice.org/75186
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Improve the plugin to avoid generating false+ with the special case of
querying XInterface (what the code calls normalisation).
Also ignore places where the querying is dealing with ambiguous base
classes.
Change-Id: I23b2b2fa6618328fafc4707b94c26582a462ea87
Reviewed-on: https://gerrit.libreoffice.org/74993
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
lcov points out these were not covered previously. Also, Word maps TH to
underline and EQ to nothing, so do the same.
Change-Id: I994f78cbe1c6c2edec73edc8944f739e2a7cb8d8
Reviewed-on: https://gerrit.libreoffice.org/76144
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Iafd8c2a80d9abab419ada995f18221212434df54
Reviewed-on: https://gerrit.libreoffice.org/76136
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
like sync ones do, so vcl knows those frames are modal-locked,
so e.g. a blank calc document with a modal async dialog open,
e.g. page dialog, is not considered a candidate for reuse
if soffice is instructed, e.g. via command line pipe, to
open another calc document
Change-Id: Id24c2ca5277e5a0e379a3e4f718514ca5e9feb03
Reviewed-on: https://gerrit.libreoffice.org/76145
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5177b41aa3be91f1b5003e49a729757405eae4d5
Reviewed-on: https://gerrit.libreoffice.org/75184
Tested-by: Jenkins
Reviewed-by: Roman Kuznetsov <antilibreoffice@gmail.com>
|
|
Change-Id: I3300ae21c74f5a25c767ce643e93d2232f3b9381
Reviewed-on: https://gerrit.libreoffice.org/76123
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
The problem was that the first and second node were not actually merged
by a redline, so moving the frames doesn't make sense.
(regression from 41d8ca9686c7c184f586e99674b443c34bfd4f33)
Change-Id: Ib401e4b0b2b207666f65c038ab5c346807bfea92
Reviewed-on: https://gerrit.libreoffice.org/76125
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I888ca249e0e9551c74611dcfb8ba7c7c1dc36880
Reviewed-on: https://gerrit.libreoffice.org/76133
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Uhm... maybe missed traslantion from German?
Anyway, this just to spot it to smarter ones
Change-Id: Icba3458d9acf9d123a73973c749c94aebd518881
Reviewed-on: https://gerrit.libreoffice.org/75258
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: Id9923031c1fe91ba71dfe8d68cbe23b72e9637b5
Reviewed-on: https://gerrit.libreoffice.org/76143
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ied76faa2a2745f16d67484d9a7f587081379f3c7
Reviewed-on: https://gerrit.libreoffice.org/76137
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5c0744c4e348f50a22f9c687659310f6c75178be
Reviewed-on: https://gerrit.libreoffice.org/76129
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie7555620655b890b9790300e2f19c40b3b55d381
Reviewed-on: https://gerrit.libreoffice.org/76138
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I55bddd8f152f34919e9818048aaf2a77a94ccaf0
Reviewed-on: https://gerrit.libreoffice.org/76130
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|