Age | Commit message (Collapse) | Author |
|
Change-Id: I48993192ec00aaf1d85cf65b6a12aacdcee67176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132359
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
> workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:967:17: runtime error: applying zero offset to null pointer
> #0 in ft_var_get_item_delta at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:967:17
> #1 in tt_hvadvance_adjust at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1138:13
> #2 in tt_hadvance_adjust at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1162:12
> #3 in tt_face_get_metrics at workdir/UnpackedTarball/freetype/src/sfnt/ttmtx.c:326:11
> #4 in TT_Get_HMetrics at workdir/UnpackedTarball/freetype/src/truetype/ttgload.c:104:5
> #5 in tt_get_advances at workdir/UnpackedTarball/freetype/src/truetype/ttdriver.c:269:9
> #6 in FT_Get_Advance at workdir/UnpackedTarball/freetype/src/base/ftadvanc.c:97:15
> #7 in af_shaper_get_elem at workdir/UnpackedTarball/freetype/src/autofit/afshaper.c:673:7
> #8 in af_latin_metrics_check_digits at workdir/UnpackedTarball/freetype/src/autofit/aflatin.c:1105:21
> #9 in af_latin_metrics_init at workdir/UnpackedTarball/freetype/src/autofit/aflatin.c:1156:7
> #10 in af_face_globals_get_metrics at workdir/UnpackedTarball/freetype/src/autofit/afglobal.c:462:17
> #11 in af_loader_load_glyph at workdir/UnpackedTarball/freetype/src/autofit/afloader.c:306:13
> #12 in af_autofitter_load_glyph at workdir/UnpackedTarball/freetype/src/autofit/afmodule.c:489:13
> #13 in FT_Load_Glyph at workdir/UnpackedTarball/freetype/src/base/ftobjs.c:978:19
> #14 in FreetypeFont::GetGlyphOutline(unsigned short, basegfx::B2DPolyPolygon&, bool) const at vcl/unx/generic/glyphs/freetype_glyphcache.cxx:903:19
[...]
during CppunitTest_svx_unit
Change-Id: I6d45ec44006458350629edf06b8ec092a450ea05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132357
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2d3e00a93cb4f089c043c0067c8026cc9fc78301
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132329
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
> [_RUN_____] testPDFAddVisibleSignatureLastPage::TestBody
[...]
> warn:sal.osl:2861871:2861910:sal/osl/unx/process.cxx:343: ChildStatusProc : starting '.../instdir/program/xpdfimport' failed
> warn:sal.osl:2861871:2861910:sal/osl/unx/process.cxx:344: Failed to launch child process, child reports ENOENT
> warn:sdext.pdfimport:2861871:2861871:sdext/source/pdfimport/wrapper/wrapper.cxx:1090: executeProcess of file:///.../instdir/program/xpdfimport failed with 4
when building CppunitTest_vcl_filter_ipdf from scratch
Change-Id: Id155ee09eb90b4bfb0416ffa458554a126db9747
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132334
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...ever since 24b06b9c6bdb777dff385b0fbfc81d55d3d013a1 "log access violation on
windows tinderboxen"
Change-Id: I8a26135131774d0c9fd160b805a3ab798a216cf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132349
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I7d7320e10c71e02606da192ee877f1df94d53c88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132318
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
...like my local ASan+UBSan build, which now happened to fail once with
> Failed: TestReplacePerformance (t = 60 s)
> Tests passed: 0
> Tests failed: 1
when the machine was under load during a parallelizing `make check`, following
up on 3564b5c6e93b2bf5881b359015efae351dbe8342 "Adapt test to slow builds"
Change-Id: I8f0c8f7e6e145b6d5009f48d2af865ea5caab375
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I38166d36e9e8518ab86ded7ab630a35f3a0c39d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132268
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
...rather than relying on a timely call to ~GtkSalMenu (which, like the added
call of ShowMenuBar(false), would also call the relevant
GtkSalMenu::DestroyMenuBarWidget in vcl/unx/gtk3/gtksalmenu.cxx).
The call to ~GtkSalMenu can be delayed arbitrarily, when the owning VCLXMenuBar
(which owns a VCL MenuBar, which in turn owns the GtkSalMenu) is e.g. held by
some Java extension code (as in the case of the LanguageTool extension used in
tdf#147668). So when a SystemWindow was switched from e.g. showing a Writer
document to showing the start center, SystemWindow::SetMenuBar(nullptr) was
called to remove the Writer menu bar (before calling SystemWindow::SetMenuBar
again to install the start center menu bar), but because ~GtkSalMenu was not
called promptly, the Writer menu bar widget was not removed, and the
SystemWindow ended up with a stack of two different menu bar widgets drawn at
its top.
So when SystemWindow::SetMenuBar(nullptr) calls MenuBar::ImplDestroy, use that
as a hint to any underlying SalMenu implementation that it shall be removed and
call ShowMenuBar(false). For the GtkSalMenu implementation, a call to
ShowMenuBar(false) happens to do what is necessary here. But for the QtMenu
implementation it would cause the menu bar to disappear forever from the given
top level window, as subsequent calls to QtMenu::SetFrame (vcl/qt5/QtMenu.cxx)
obtain the same, now invisible
mpQMenuBar = pMainWindow->menuBar();
again from the top level window; so just always call ShowMenuBar(true) from
MenuBarWindow::SetMenu. And for other SalMenu implementations the added
ShowMenuBar calls appear to not cause any trouble, even if they would not be
necessary for them.
Change-Id: I66d5edf6b49a1c616fe849f6996570b5b00258ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132126
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
Change-Id: I3150d62263b87ec9f63fa6406f74c26d42b47a97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132356
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <rizmut@libreoffice.org>
|
|
SvxColorTabPage::FillItemSet() has to produce a color item that has the
theme index, which means SvxColorTabPage::SelectValSetHdl_Impl() has to
change the current color to an svx::NamedThemedColor.
The rest is just fallout from this, now that the current color has
theming metadata.
Change-Id: If0018c651239ba74f45745e69e41ff7040ac9b97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132327
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I770008bf0a775c108019c2005b6ec73ee9702a19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132337
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This only allows the default richText type, the others are not yet
handled.
Change-Id: I39f73ccd9e2c1f0db5735cf97301b01482063d1d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132350
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Like in DOCX for RTF there is exactly same behavior for paragraphs
inside cells. They do affect table breaking over the pages.
So:
1) Enable "TableRowKeep" doc setting for RTF documents.
2) Do not ignore \keepn token for paragraphs in tables.
Change-Id: I11e45ca9114c792b8cdbeb77dd51359717129651
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132305
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
In case of copy/pasting of whole column(row) and its undo/redo may
result in column(row) width(height) changes. Hence a corresponding
sheet-geometry invalidation message needs to be sent to the lok
client(s).
Change-Id: I7aa471d9770fc21c567a3c6f5d5926df0fd5dacb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132174
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Change-Id: I588484955ad3ad4c5ec3bfa9f5a844096c768ff2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131725
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
(cherry picked from commit 9bafce808b6d301b17ee60da452a41cd4b7cf02c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132173
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Change-Id: I4b433c8f7123fe33f1b106cbf45216d2b0c73dba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131691
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
(cherry picked from commit 3902718e6daed24e4fe3653b4241f94e802c4e56)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132172
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
to get correct id for the new cell-note.
Change-Id: I4df492ad91faad5797ba513f9a3aa9abd2baf88f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131690
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
(cherry picked from commit acafc2823f917b6f6299fa0b65a0d7461531c8a5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132171
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Problem:
When a cell containing comment is copied and pasted to another cell, the
cloned comment/annotation in the target cell has the same id as the
original one. The lok clients depend upon the id of each comment to
identify them and update coordinates when updates are requested through
.uno:ViewAnnotationsPosition. So the client does not have enough
information to distinguish between comments of same id.
Conflicts:
sc/source/core/data/postit.cxx
Change-Id: Iebd7281113e0830826aff1bbdaae234bd5d5cd4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131689
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
(cherry picked from commit dd229e4cd9a0211c9a80031da1d2f7fb71b6683e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132170
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
See the screenshots: https://github.com/rizmut/libreoffice-style-colibre/pull/48
Change-Id: Ief6b29dd9e4f4702b8cc0932b9d52d70dfa1958e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132340
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <rizmut@libreoffice.org>
|
|
(Callouts and Vertical Callouts)
Change-Id: I5531550a21536351bd56e1da365d0bc640bc9f32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132341
Tested-by: Rizal Muttaqin <rizmut@libreoffice.org>
Reviewed-by: Rizal Muttaqin <rizmut@libreoffice.org>
|
|
> warn:vcl.builder:2475462:2475462:vcl/source/window/builder.cxx:479: DBG_UNHANDLED_EXCEPTION in VclBuilder
> when: Unable to read .ui file exception: com.sun.star.container.NoSuchElementException message: "file:///.../instdir/share/config/soffice.cfg/svt/ui/editcontrol.ui at xmlreader/source/xmlreader.cxx:66"
and
> warn:vcl.builder:2507015:2507015:vcl/source/window/builder.cxx:479: DBG_UNHANDLED_EXCEPTION in VclBuilder
> when: Unable to read .ui file exception: com.sun.star.container.NoSuchElementException message: "file:///.../instdir/share/config/soffice.cfg/sfx/ui/tabbar.ui at xmlreader/source/xmlreader.cxx:66"
when building CppunitTest_sw_layoutwriter from scratch
Change-Id: I043db8e1b25a8b990bcad542dcbe533a57654c05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132323
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
no logic change intended
Change-Id: Iebb8df604aa69829536e3cab10b33056e4cdf78e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132331
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Idem for "Columns"
Regression from:
commit 763e5d233d18a26f64dd8c4db67ce62ee289832e
Author: Julien Nabet <serval2412@yahoo.fr>
Date: Wed Mar 16 20:35:33 2022 +0100
Related tdf#114286: put duplicates commands in GenericCommands (DeleteColumns)
Change-Id: Iecfa09729ea1b237fb6994be4b3ceaaa3ad126df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131680
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
commit 52a695d2ceb4231a9fcc419959e29023ecef037b
Author: Julien Nabet <serval2412@yahoo.fr>
Date: Thu Mar 17 11:01:47 2022 +0100
Related tdf#114286: put duplicates commands in GenericCommands (DeleteRows)
Change-Id: I100297d10b2643c5ddad7753a7c1032526ce06cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131699
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Change-Id: I790f2b686e27195b137db3b2d6385787e1829e04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132325
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I14e8fec80e06403868a80cabfe5231420bdd6f2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132328
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Idc2fc8157a84b010be4855d8aa7c111d4594b4f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132326
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: Ie50eeb9bcf1670b014ec600b62ef83a4fb27ee59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132330
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
> sw/source/filter/html/parcss1.hxx:163:35: runtime error: -1.0458e+22 is outside the range of representable values of type 'int'
> #0 in CSS1Expression::GetSLength() const at sw/source/filter/html/parcss1.hxx:163:35
> #1 in ParseCSS1_text_indent(CSS1Expression const*, SfxItemSet&, SvxCSS1PropertyInfo&, SvxCSS1Parser const&) at sw/source/filter/html/svxcss1.cxx:1955:45
during recently introduced testForcepoint94::TestBody in
CppunitTest_sw_layoutwriter, where sw/qa/extras/layout/data/forcepoint94.html
contains "text-indent: -18446744073709551616.0cm"
Change-Id: I1070f07ea0304a3813ab9a58441c9d7e45f79ffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132322
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I652a079f6bf31c6b4a278c4b246404684c771ff5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132317
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Impress and Calc used to dump the same image file
as many times as it was featured in the document,
resulting redundant, sometimes huge documents.
Note: using only checksum to recognize image duplication
is a regression, because checksum collision results
image loss. This is a very unlikely event, and
the following commits have got the same problem.
The solution is comparing the images with the same
checksum byte for byte.
See also commit b484e9814c66d8d51cea974390963a6944bc9d73
"tdf#83227 oox: reuse RelId in DML/VML export for the same graphic"
and commit 797fef38612fb2fd62d1f6591619b9361e526bca
"tdf#118535 DOCX export: save header image once".
Change-Id: I9f233d521941381746634cf4f9b5991da0dadda9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131928
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
With Clang14 the binutils readelf prints out a lot of warnings
that are presumably related to Clang's switch to DWARF5, but
llvm-readelf is silent about it. And in general it seems to make
sense to first try to use the related tool.
Change-Id: If0dd4f267bae080b7053a6944cd24df7f9b9cf69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132309
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I8762e84a34a116778bd0bced706d631db4761a01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132302
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8b2c558c733af3d7662f668af47e962e252ee339
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132311
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1bcf8f79213245fdf135d6d3b2aafea6ed99f5b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132296
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I8d2ae21cee9ba021a3e7bc0efd7f6a67768105f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132280
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Building LO with WASM native EH and Emscripten 3.1.6+, the link
fails with a missing "emscripten_longjmp" symbol. Actually the
old build was simply wrong, because the emscripten_longjmp
function is just used for the Emscripten SjLj and not the native
WASM SjLj implementation. Linking just worked, because the used
libcompiler_rt-wasm-sjlj-mt.a lib was incorrectly providing that
symbol, which 3.1.6 removed.
But since running the NEH build still fails early in the same way
then before in FF nightly 100 and Chrome (= failure in the LO job
scheduler calling Task::UpdateMinPeriod for the "desktop::Desktop
m_firstRunTimer" timer, resulting in a WASM VM "RuntimeError:
indirect call signature mismatch"), there is still no way to know,
if nothing else it missing. The Emscripten / JS EH build still
works without any code changes. And it's not the first call on
a job object that fails...
And unfortunatly, because Qt itself also uses libpng, it also uses
SjLj for error handling, like LO in the image import, so the Qt
build must also be patched to build with "-s SUPPORT_LONGJMP=wasm".
Simply enough to do (see README.wasm.md). LO's configure now
detects that symbol and will bail out on incompatible Qt and LO
build setup.
See https://github.com/emscripten-core/emscripten/issues/16572
Change-Id: I3a1877f3aeb77873906176b9d3cd1ea92973f1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132139
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Flags and attributes can be set even for unallocated columns.
Change-Id: I7c4e6b9c8f9359620f6c2ab06fe0563183b88f9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132304
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
* Update helpcontent2 from branch 'master'
to f62d08a3fb7e4b3e56c06cf643354a2a16a1aaba
- tdf#145754 Corrections to 'Option Compatible' Basic help page
Change-Id: Ie44b6b8717de38073dc791c286ce778e7595db3e
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/132038
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Regression from commit 938a4d6624a78f3e272b3c4c07f314cb0c6db723
(tdf#128375 sw: fix copying RES_PARATR_LIST_AUTOFMT to different SwDoc,
2019-11-01), the problem is that we may get an autofmt pool item which
is set, but its style handle is empty. Assume that this is the same case
as having no autofmt at all.
Change-Id: I87494fd04687d31201b4ec712cb0fb1ec7362b46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132301
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I775baf9a2c9599b10eb855535ac0f8e438dd863b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132279
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id99cbf2b50a4ebf289dae6fc67e22e20afcda35b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131976
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
old ones default to the current all zero case and continue to work
as before
Change-Id: I6fe3b02fafcce1b5e7133e77e76a5118177d77af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131974
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I5c56eae4456a03550770035610745de3be074679
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132299
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic39fd3579623563adf16025442bb634a273decb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132298
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id33a39a7a65849a4ca98b43a88e60d5a96eaf5de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132297
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Allows adding custom jump list categories to Windows Task Bar
Change-Id: I13b6c3ad5de386cf74e2b346f10889bc46a8ad4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131540
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
Qt Creator 7 switched to using Clangd as the
default backend for the code model. [1]
After upgrading, `.qtc_clangd/compile_command.json`
started showing up.
[1] https://www.qt.io/blog/qt-creator-7-released
Change-Id: I3cf30f1ef2873523d76c15c39d2d24c6227f8017
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132290
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This is meant to represent inline structured document tags (<w:sdt>
elements in DOCX) or content controls (as Word users know this).
Don't confuse this with block-level, cell-level or table-level content
controls, which are not covered here.
You may wonder why fields or fieldmarks can't be used to represent this.
The problems are:
- a fieldmark can contain a paragraph break, inline content controls
can't
- content controls must be a well-formed XML element, while fieldmarks
can start/end at random document model positions
- fieldmarks are supposed to have a field command and a result result
(with a separator between the two), but content controls don't have a
field command
- mapping to a field has the problem that Writer fields can only have a
single text portion / run, but content controls can have multiple ones
So model content controls with a meta-like text attribute which covers
all these cases.
SwContentControl is mostly empty as a start, it can track more data in
follow-up commits. SwTextContentControl and SwFormatContentControl are
the matching text attr and pool item subclasses.
Change-Id: I1e57f7756cf87041975371483ec4fc8abf875dfe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132291
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I35bef5643d8a620aaa001bb1f4f7a9a60779ed97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132288
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I94a836d7424eb561af623fee9d3a7e6d307cf065
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132287
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|