Age | Commit message (Collapse) | Author |
|
nothing to do with the crash though
Change-Id: If7645a904de9147d20f548017bf5390fc57af6cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118626
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
the other uses of SdrObjListPrimitiveHit operate in Logic Position
Change-Id: Id6a834a17e6e2252bd4f58d10cd95f7425191203
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118613
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9cd7ad0eca1a6fb471a284fb2828a7ad12816337
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117024
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 8b3ff370ab0fe2e7593a69513c8ff3df35810c4e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118107
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: Ice9d2a155c4237b30134bd8faf7931ec980829e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118296
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I90aefc10f9ddddeb64a65799480777bc4287abae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117107
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit dd5bf12193471f064bf7f581dd1b21783390e735)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117217
|
|
Regression of bda05ba17362222b74727872579b65b3fa14e3d8
"tdf#41466 DOCX import: fix VML v:shape/v:textbox".
Co-authored-by: Tünde Tóth
Change-Id: I8762aa8a710c3a37290e1db854b8cc86db6757b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109436
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 2ffdd37067926ddb841c6055205f267b96706945)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117973
Tested-by: Jenkins
|
|
Instead of style:num-prefix and style:num-suffix new list format
is much more flexible for storing list multilevel numberings.
Now it is possible to have not just prefix/suffix but any random
separators between levels, arbitrary levels order, etc.
Internal LO format for list format is changed: instead of placeholders
like %1, %2, etc we right now use %1%, %2%... Reason: for ODT documents,
having more than 9 levels there is ambiguity in "%10": it is "%1"
followed by "0" suffix, or "%10"?
Aux changes:
* removed zero width space hack: since format string is always defined
this hack is interfering with standard list numbers printing
(see changes in ooxmlexport14.cxx, ww8export3.cxx tests)
* changed cross-references values to lists: they are now including full
list label string: previously this was bit self-contradictory (see
changes in odfexport.cxx and check_cross_references.py tests)
Conflicts:
sw/qa/extras/odfexport/odfexport.cxx
Change-Id: I9696cc4846375c5f6222539aeaadbca5ae58ce27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117156
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118040
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
|
|
processing EE_NOTIFY_PROCESSNOTIFICATIONS from an EditEngine with an
UpdateMode mode of false will just to on to cause
AccessibleTextHelper_Impl::GetTextForwarder to throw an exception as a
Frozen EditEngine is considered Invalid so return early instead
Change-Id: I86f9647b7bf839cf3c7cf2f029be8c7c5aeef1f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118070
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Icfcb4199dcd755fb20e14a8166571b6d6e763f2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117671
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
(cherry picked from commit 9e8c35cc3f1f5e1c08afd46e0d0fbc07f1ff21f9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117721
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
regression from weld-ing (c85fcc6e1994eb8e079aaca85066ab4d67149c15)
Change-Id: Iad0725fd4542ecdddb65092846dbf9d103016d9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117408
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <bubli@bubli.org>
(cherry picked from commit 7a717c8b9319edcc12e50ab78554b8e0e7049cbf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117419
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
VCL default would be 500k pixels, i.e. a 2" x 1" shape at 600 dpi would
be already truncated from 1200 pixels width to 1000 pixels. That's a bit
too extreme, use a larger limit in the sw HTML export.
Change-Id: I52b85d77cd27410d53c700a89190c99348de5e19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117287
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(cherry picked from commit 3c46fd3d727e4885fedef7c9f3fcd6f4c9a9ebb9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117296
|
|
At least UITest_impress_tests started to fail at
> ==608818==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x6020000ef270,0x6020000ef276) and [0x6020000ef274, 0x6020000ef27a) overlap
> #0 in __asan_memcpy at ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
> #1 in RemoveWhichRange(unsigned short const*, unsigned short, unsigned short) at svx/source/svdraw/svdetc.cxx:413:17
> #2 in SdrObjEditView::SetAttributes(SfxItemSet const&, bool) at svx/source/svdraw/svdedxv.cxx:2222:19
> #3 in SdrCreateView::SetAttributes(SfxItemSet const&, bool) at svx/source/svdraw/svdcrtv.cxx:883:29
> #4 in SdrView::SetAttributes(SfxItemSet const&, bool) at include/svx/svdview.hxx:193:96
> #5 in sd::View::SetAttributes(SfxItemSet const&, bool, bool, bool) at sd/source/ui/view/sdview.cxx:488:28
> #6 in sd::DrawView::SetAttributes(SfxItemSet const&, bool, bool, bool) at sd/source/ui/view/drawview.cxx:288:27
> #7 in sd::TextObjectBar::Execute(SfxRequest&) at sd/source/ui/view/drtxtob1.cxx:819:21
> #8 in SfxStubTextObjectBarExecute(SfxShell*, SfxRequest&) at workdir/SdiTarget/sd/sdi/sdslots.hxx:17883:1
[...]
(followed by
> ==647521==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000258856 at pc 0x0000002f7b0a bp 0x7f7f7a69fdb0 sp 0x7f7f7a69f560
> READ of size 6 at 0x602000258856 thread T9 (cppu_threadpool)
> #0 in __asan_memmove at /data/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:30:3
> #1 in RemoveWhichRange(unsigned short const*, unsigned short, unsigned short) at svx/source/svdraw/svdetc.cxx:413:17
> #2 in SdrObjEditView::SetAttributes(SfxItemSet const&, bool) at svx/source/svdraw/svdedxv.cxx:2222:19
> #3 in SdrCreateView::SetAttributes(SfxItemSet const&, bool) at svx/source/svdraw/svdcrtv.cxx:883:29
> #4 in SdrView::SetAttributes(SfxItemSet const&, bool) at include/svx/svdview.hxx:193:96
> #5 in sd::View::SetAttributes(SfxItemSet const&, bool, bool, bool) at sd/source/ui/view/sdview.cxx:488:28
> #6 in sd::DrawView::SetAttributes(SfxItemSet const&, bool, bool, bool) at sd/source/ui/view/drawview.cxx:288:27
> #7 in sd::TextObjectBar::Execute(SfxRequest&) at sd/source/ui/view/drtxtob1.cxx:819:21
> #8 in SfxStubTextObjectBarExecute(SfxShell*, SfxRequest&) at workdir/SdiTarget/sd/sdi/sdslots.hxx:17883:1
[...]
> 0x602000258856 is located 0 bytes to the right of 6-byte region [0x602000258850,0x602000258856)
> allocated by thread T9 (cppu_threadpool) here:
[...]
if the memcpy were replaced with memmove) after
8aaa28ed43978a9a4a20d62368410a57ec05c23f "Assert on valid order of which ids in
ranges on SfxItemSet creation":
Where in the past it had called
RemoveWhichRange({10951, 10951, 4007, 4007, 0}, 4007, 4062)
and
RemoveWhichRange({10950, 10950, 4007, 4007, 0}, 4007, 4062)
on wrongly sorted ranges, for which the implementation of RemoveWhichRange
happened to work, it now calls
RemoveWhichRange({4007, 4007, 10951, 10951, 0}, 4007, 4062)
and
RemoveWhichRange({4007, 4007, 10950, 10950, 0}, 4007, 4062)
on correctly sorted ranges, which uncovered the broken implementation.
Given that RemoveWhichRange is presumably not hot (e.g., being called just two
times during UITest_impress_tests), turn it into a less sophisticated, but also
likely less error-prone algorithm.
(Leaving unit tests as a TODO, given that RemoveWhichRange is not
currently exported from Library_svxcore, and the existing CppunitTest_svx_unit
links against Library_svxcore rather than using
gb_CppunitTest_use_library_objects.)
Change-Id: I8a1c1d5db8073928ad2f6e88d581f24a0e882925
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117264
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 541f94df85756d3a383b1f9ba49841ca0011b52e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117294
|
|
...down in svl::detail::CountRanges during e.g. CppunitTest_sd_tiledrendering,
after 8aaa28ed43978a9a4a20d62368410a57ec05c23f "Assert on valid order of which
ids in ranges on SfxItemSet creation" and
90cb57eb53e28ecb983001bf8f018577abb6d145 "Workaround internal compiler error on
tb77"
Change-Id: I8ff49384a86676a97ec876ef08426b978e39f6d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117168
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit d3e51bce28a759916e9a3988172ba02b1db66641)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117127
|
|
Change-Id: I2c2b655b512e4e7869fe3784f1b073ecdbd0dac9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117122
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
As reported in https://ci.libreoffice.org/job/gerrit_windows/98360/console :
C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/svx/source/svdraw/svdedxv.cxx(2639): fatal error C1001: Internal compiler error.
(compiler file 'msc1.cpp', line 1591)
To work around this problem, try simplifying or changing the program near the locations listed above.
If possible please provide a repro here: https://developercommunity.visualstudio.com
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/svx/source/svdraw/svdedxv.cxx(2631): note: while evaluating constexpr function 'svl::ItemsArray'
INTERNAL COMPILER ERROR in 'C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1427~1.291\bin\Hostx64\x86\cl.exe'
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
tb77 uses VS 16.7.7 (cl.exe is under Tools/MSVC/14.27.29110); tb68 with
cl.exe under Tools/MSVC/14.28.29910 has no problems compiling this.
Let's make the code simple for now, until we upgrade the tooling on CI.
Change-Id: I10aaf289454c89b2f49b4be947627a9a3be30fde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117137
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 90cb57eb53e28ecb983001bf8f018577abb6d145)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117118
Tested-by: Jenkins
|
|
This allows to make sure we actually use sorted which ranges,
and then it's safe to call SfxItemSet::MergeRange when needed.
Also this change relaxes the previous requirement that ranges
must be separated by at least one; this allows to have adjacent
ranges, like in
RES_FRMATR_BEGIN, RES_FRMATR_END-1,
RES_GRFATR_BEGIN, RES_GRFATR_END-1,
where RES_FRMATR_END is equal to RES_GRFATR_BEGIN. Allowing this
makes possible to (1) self-document the ranges, so it's clear
which ranges are included; and (2) be safe in case when these
constants would change, so that the one merged range would not
unexpectedly contain everything inserted between RES_FRMATR_END
and RES_GRFATR_BEGIN.
Change-Id: Iaad0f099b85059b3aa318a347aa7fbd3f6d455c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116909
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 8aaa28ed43978a9a4a20d62368410a57ec05c23f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117114
|
|
Change-Id: Ia42158597588fe802a2f06a6e8e59f372c62c022
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117031
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
ParaLineSpacingControl::Initialize() is another place where
SfxItemState::UNKNOWN was just used as a placeholder for
a non-set SfxItemState (aka could not be queried)
Change-Id: I95ad01579e5aa4c86ace619e2201481742297c2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117016
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
FontworkBar::getState does not need to check for SfxItemState::UNKNOWN
at all, actions solely depend on FontWork object being selected.
This also greatly simplifies that method. Also, the optimization
by passing in a variable to checkForSelectedFontWork and remember
if already computed can be removed - also in other places where
it had to be given, but was not re-used at all
Change-Id: I35b1f36195feb1d645619665d2dd65a84b75b118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117014
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I41ffe5c66e56ec7add2d4fcbb129ae2e3ff13b20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116915
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
This allows to create it e.g. in Basic macros using CreateUnoService
Change-Id: I949d3b92c83cd9e763244f70b22f0f367b93cb48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116970
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
No need to check for SfxItemState::UNKNOWN, all states depend on
selected SdrObejcts/E3DObjects anyways
Change-Id: I13be6494229c18f514da3e0229d0896b237508c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116939
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: Iec21851d69f4a8d5f557e9ed2d30e5f680cd62c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116943
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I020424db94a6fbdba22ff887b912d3f7bb459502
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116709
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This changes the way how different parts access positions of lines and
paragraphs. Now there is ImpEditEngine::IterateLineAreas, which performs
uniform iteration over all ParaPortions and lines in order, calling a
user-provided callback function for each portion and line; it passes
all information about current portion, line, area, and column to the
callback, and checks the return from the callback, to decide if it needs
to continue iteration (in case when callback indicated that if doesn't
need further data), and if it needs calling the callback for the rest of
current portion's lines.
This allows to have the code that calculates and iterates dimensions of
lines in one central place, without the need to have duplicating logic
in several places.
One important exception is ImpEditEngine::Paint, which iterates without
ImpEditEngine::IterateLineAreas, because it does many atomic paint
operations in different points of iteration process, and implementing
ImpEditEngine::IterateLineAreas to call callback in the required places
would require increased complexity, which is left for a future change.
To make that possible, ImpEditEngine::IterFlag should be extended to
indicate additional requirements.
Note that in fact, ImpEditEngine::Paint was taken as the model for
implementation of ImpEditEngine::IterateLineAreas, with its detailed
handling of all the vertical offsets like additional line spacing and
interparagraph spacings that depend on context.
The notable result of the centralization of the iteration code is slight
change of heights reported by ImpEditEngine::CalcTextHeight. Previously
it simply added all pre-calculated heights of portions, and not taking
into account all the spacing handling that ImpEditEngine::Paint did,
which was inconsistent (calculated height was different from painted
height). Now ImpEditEngine::CalcTextHeight should provide more accurate
results, which required small changes in the unit tests.
Change-Id: I33cbb978deb974b314d36fda8674186a03991107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116034
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This uses existing ODF markup, as used by Writer's text frame:
style::columns child element of style:graphic-properties, its
fo:column-count and fo:column-gap attributes. No ODF extension
is required.
Since currently only columns with same width and spacing are
implemented, without additional settings, style:column child
elements are exported, but ignored on import.
This adds new property to css::drawing::TextProperties service:
TextColumns (of type css::text::XTextColumns).
Change-Id: I7e63293e5814b281ceec8a9632e696322d3629e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116035
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I056aad9474ca18134d1f1686a53618cc9ab3d525
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116038
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...ever since the code's introduction in
ea1ca189b561e47d3b872f40628e6af224355626 "added api for glue points"
Change-Id: I221632d243c8c778c711c3f001676ff26043d0fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116825
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As I experimented with redesigning the whole
Item/ItemSet/ItemPool paradigm, I alredy checked that
SfxItemState::READONLY is not used (and no one
really knows what it should do or stands for).
Since a removal of complexity is needed to get forward
with that redesign and I already made some experiences
in branch item_refactor2, I propose to remove this
state. It is not really used (gets never set).
It is mirrored/used in the UNO API in
css::frame::status::ItemState as 'READ_ONLY', but also
not used in the office's code. ItenmState itself is
used in three places, but all set the Item involved
by using a SfxVoidItem to state SfxItemState::DISABLED,
which I described in ItemState.idl. This means that
no state of READ_ONLY in UNO API is ever imported
to office code as DISABLED state at all, so not
used.
I also marked it as deprecated in the *.idl file.
I think - including the experimenting in the
mentioned branch - that this is safe for now. I
already run a full 'make check' on the changed stuff.
Change-Id: I8c15cf7b4f803076ecaaea67659f6e022ac7ef70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116752
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
GetTextFitToSizeScale and SdrTextObj::GetFontScaleY both didn't
initialize outliners properly, and thus returned wrong results.
Change-Id: I6fe63c51ed838a0d0fafdfa03597cac97ce29831
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116765
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
But leave the CSS pixel size of them unchanged in the HTML markup.
Also add some documentation on the various options, so one doesn't have
to dig them out from testcases.
Change-Id: I6c6ee4e9c98d674f44e7c5835f2e6a6737e13f34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116722
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
- the twips logic size was set, but it was consumed as mm100 logic size,
so the pixel size was about half of the correct one
- the HTML export didn't write a logic size ("CSS pixels size") for
shapes
Change-Id: I37f6b4acde9d1298fae81f9975e9db95485631ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116691
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I4dcb23dc5773c4ea198d1327f88d931afb1f3483
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116688
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I0e2811802f17831097a86103571b505a7557717a
Signed-off-by: merttumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116040
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116299
Tested-by: Jenkins
|
|
Change-Id: I8a17c73781a3399b214d5655b83036652933a90a
Signed-off-by: merttumer <mert.tumer@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115689
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116298
Tested-by: Jenkins
|
|
This is no longer needed, we only call VCL functions in svx/ today.
Change-Id: I741ed9bc4c66067ea423211b8f16305b0e4099fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116622
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ife68cef7eeab0010c4d233c81e3bee808c2c1c28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116615
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia69d4feb059ece2068d0229887749e258bcacf70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116608
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
calling code seems to think it's quite fine to do, and is
happy with a nullptr return
Change-Id: Ia003364ad91a56f2f80ada3076a69d79b30e9c35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116573
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I856aab424bd4378d8c115e36971fd76fe7a7feed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116458
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7903565a468fc0fbec603c88b92cca6560a86728
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116424
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
SvxBackgroundColorItem is just copied from SvxColorItem. There is
nothing special to SvxBackgroundColorItem class. SvxColorItem is a
generic item and it's used on many places related with colors. We can
use SvxColorItem for background colors too.
Change-Id: Iacea31a7557b806e95f5859ff60add9a2626ec05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116282
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I015df0308696da3c4fe1ed45afd01185d0ce7d76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116403
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
my fault, from a recent commit. besides defeating the dispose(), it
should also be checked from the call sites.
Change-Id: Ia09580d4224bcf78e5684015c747105fa6606878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116383
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I15779eca607f27a758575f4f095910277aa85eda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116377
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia839a25cb75782b7b92372d876a41a7fd2e830d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116370
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I986cf078004a292eb3560857274e5542330d203d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116329
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
use std::optional where the code needs to control the lifetime of the
object explicitly
Change-Id: Ia550ce051360f68911abc68c945a97d62a637b06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116291
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If3cd60bd48f640c353fd4c28449faed2cdcebdda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116243
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use a macro to do the same checks for all Executable with glxtest
or vclmain usage. Both are static libraries, so every user has the
same dependencies. Introduces:
* gb_Executable_use_vclmain
* gb_Executable_use_glxtest
Change-Id: Ib80b4e7c6f5078d47ad8f1ec5708a7174415f705
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116145
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|