...instead of joining and later re-spawning one. This helps with the current
Emscripten setup (see 5b1df7709d "Document the
Emscripten threads issue"), and probably doesn't matter much either way on other
platforms (so just get it in unconditionally). (Renaming the delay_ member
variable to delayOrTerminate_, to make its overall role more clear.)
(I ran into this when trying to turn the Emscripten build from starting up with
a Writer document to starting up with the start center, and then manually
opening a new Writer document. The resulting different usage scheme happened to
exhaust our current -sPTHREAD_POOL_SIZE=4 pool quickly, so this is one of
multiple commits to address that.)
Change-Id: I1bd28604b4640d2afad982bfd82b1acee8200e26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170993
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Despite that we bailed out when both old and new value set,
gcc-13 cannot see that.
Change-Id: Ie727a14bb29a4b1cc304d2ce077c62f72cece19f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170973
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
when adding a change in the document (Track changes mode), round 4
Addresses "situation 4" when a new change makes a change to an entire
previous change or to multiple previously tracked changes.
Change-Id: I02175db6c7bc1258f8e7c05835b05ff79b7d7b83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170984
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Tested-by: Jenkins
::pData type
Casting a void* RedlineData::pDate to either a SwRedlineDataParent*
or SwRedlineDataChild* works because of the order and variable types
declared in the SwRedlineDataChild and SwRedlineDataParent classes
match until an OUString is declared in SwRedlineDataParent. That
explains why the non-patched code behaves as expected even though
testing if the entry has children to determine which cast to do is
flawed. Better is to test the iterator depth which is what this patch
does.
Change-Id: I24ca0990a4edbd50a7e3dc5d0be4c5312c240921
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170860
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
for all the Text field made a global define
of the NonBreakSpaces mask
Change-Id: I7107f941ee9008415325aefe5487555d91dbf1ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170596
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
That code had been added with 9fa4eff9be
"profilesafe: Enhancements to BackupFileHelper", but it looks dubious:
For one, I cannot find proof for the claim that MSVC would run destructors of
static objects upon _exit. Building a simple C++ test program
> #include <iostream>
> #include <stdlib.h>
> struct S { ~S() { std::cerr << "hello\n"; } };
> S s;
> void f() { _exit(1); }
> int main() { f(); }
with contemporary MSVC 17.10 and executing it shows no "hello" stderr output
(see
<https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:13,endLineNumber:5,positionColumn:13,positionLineNumber:5,selectionStartColumn:13,selectionStartLineNumber:5,startColumn:13,startLineNumber:5),source:'%23include+%3Ciostream%3E%0A%23include+%3Cstdlib.h%3E%0Astruct+S+%7B+~S()+%7B+std::cerr+%3C%3C+%22hello%5Cn%22%3B+%7D+%7D%3B%0AS+s%3B%0Avoid+f()+%7B+_exit(1)%3B+%7D%0Aint+main()+%7B+f()%3B+%7D%0A'),l:'5',n:'1',o:'C%2B%2B+source+%231',t:'0')),k:32.19670284753087,l:'4',m:100,n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:vcpp_v19_40_VS17_10_x64,filters:(b:'0',binary:'1',binaryObject:'1',commentOnly:'0',debugCalls:'1',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'0',trim:'1',verboseDemangling:'0'),flagsViewOpen:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'',overrides:!(),selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x64+msvc+v19.40+VS17.10+(Editor+%231)',t:'0'),(h:output,i:(compilerName:'x86-64+clang+18.1.0',editorid:1,fontScale:14,fontUsePx:'0',j:1,wrap:'1'),l:'5',n:'0',o:'Output+of+x64+msvc+v19.40+VS17.10+(Compiler+%231)',t:'0')),k:67.80329715246913,l:'4',m:100.00000000000001,n:'0',o:'',s:1,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4>).
If there indeed were issues with MSVC and non-standard _exit, a solution might
be to use standard _Exit instead (in FatalError in desktop/source/app/app.cxx).
And for another, when bExitWasCalled was true in
configmgr::Components::~Components, it would still have called
writeThread_->join() (i.e., it would potentially still have called
writeModFile from within configmgr::Components::WriteThread::execute()), but (a)
only after waiting out its full
> delay_.wait(std::chrono::seconds(1));
(because it missed to call configmgr::Components::WriteThread::flush, which
calls delay_.set()), and (b) potentially running into a deadlock because it
called writeThread_->join() with *lock_ locked, which
configmgr::Components::WriteThread::execute wants to lock too.
(I came across this because it got into my way when trying to adapt the
lifecycle of configmgr::Components::WriteThread to the needs of the Emscripten
build.)
Change-Id: Icb4ebf00d1d316b80c29f7bd91b86614ef4ac430
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170940
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
One place that was missed was when moving from one content control
to another (for example, using the tab key).
Change-Id: I62a3af2a5a7036aaac605d592c244a58f5b65a12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170967
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This makes the "sentence" drawing area from the spelling
dialog (cui/uiconfig/ui/spellingdialog.ui) show up with
role panel instead of "unknown" in Accerciser when using
the qt6 VCL plugin.
This is the same as with gtk3, where the `TEXT_FRAME` role
is mapped to `ATK_ROLE_PANEL`.
Change-Id: I41133c51c64749ccd808cb675fe647a0daefac33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170944
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Up to now these needed to be decomposed to be
rendered and did not support animation. I already
added animation, but that was a compromize.
Done that now in the correct way, so that animation
is possible and can be directly rendered using
a FillGraphicPrimitive2D if wanted, including one
extra layer of alpha, too.
This will also enhance other primitive processors,
but of course most those that do handle that now
directly, so CairoPixelProcessor2D does that.
Note that it does not need to support animation
in any way (that is part of the primitive stack),
but just direct tiled rendering.
Change-Id: I8860098dfb3f2369e361579cf1deea7c67b662b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170937
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
we had an ODR violation with a constant named PROPERTY_DATASOURCE which
is also defined inside dbaccess
regression from
commit bacb92275c
"add dbu to --enable-mergelibs=more"
Change-Id: I315ba82e0bccc49e01bd6a438b7e671b971410dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170939
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This change fixes a vertical text glyph metrics regression that was
introduced while migrating PDF export to use metrics from HarfBuzz. The
root cause was incorrectly caching CJK glyph heights in place of widths
for vertical text.
Change-Id: I8426fc902658d1c045b42e760028f26b09eeef93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170935
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
commit 24103bdf3f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 18 08:58:10 2024 +0200
tdf#161501 icon choice ctrl: Use tab text colors
Instead of using the generic window or highlight
text color, use the specific text colors for tabs
when painting entries of the vertical tab control,
similar to how it's done for the non-vertical
tab control (see `TabControl::ImplDrawItem`).
(...)
had added code to set the font color for the different
states of a vertical tab control item, but as this
was in the `if (bSelected)` block, only the one
for selection was actually used, so the other cases
were consequently removed in
commit a4befb29f3
Author: Caolán McNamara <caolan.mcnamara@collabora.com>
Date: Sat Jul 20 19:20:13 2024 +0100
cid#1610738 Logically dead code
again.
Thanks to Chris Sherlock for pointing this out!
Reintroduce setting colors, but drop the `bSelected`
condition altogether. Drop explicitly setting a fill
color, which the implementation for the non-vertical
tab control in `TabControl::ImplDrawItem` also doesn't
do and which would e.g. result in an odd grey background
for non-selected entries when used unconditionally with
the gen VCL plugin.
I see no visual difference with or without this commit
in place on Windows or for the gen VCL plugin or the kf5 VCL
plugin with the Breeze style on Linux, but other theming/styles
could depend on according colors being set.
Change-Id: Iccf7170f2de04cead23607977ac8cf7acbc471f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170926
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
When the mouse leaves the vertical tab bar,
unset the entry to highlight as mouse-hovered,
as the previously one no longer is when the
mouse is outside the area of the tab bar.
This fixes the issue of the previously
mouse-hovered entry still being painted
with mouse-hover feedback when slowly moving the
mouse to the right away from an entry in the
"Insert" -> "Page Style" dialog with gen or kf5
at least, as shown in attachment 195467
of tdf#161501.
Change-Id: I646cab54f5031ed6a8aa88d4a162bb3a2456eec4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170923
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
It is always set, so no need to have an
icon choice control specific window bit to
specify whether or not to highlight the
currently mouse-hovered entry. Just always
do it.
Change-Id: Ib259b6b1576e1968221c4f98661a3a93e600c93b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170922
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
While GetIsDummyParaAddedForTableInSection() is true
for the entire section, it should only be used
against GetIsFirstParagraphInSection()
where the dummy para exists.
make CppunitTest_sw_ooxmlexport19 CPPUNIT_TEST_NAME=testTdf138093B
Change-Id: I457c0aa25eb7bd086c5c15bd889d9cd89c51db95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170921
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This fixes a 24.2 regression
from commit 5082d50d24
writerfilter: use content controls for text in block SDTs
which was made even worse
with 24.2 commit 7c4dba1def.
Initially, the starting mark was made as soon as SdtContent was seen.
After that, you could get a w:tbl, or a w:tc which could trigger
the start of a table, and potentially add a dummy paragraph
which needed to be jumped over (at least for the first SDT,
but not for subsequent SDTs).
In the second patch, the starting mark was made just before
the text was appended, so all of the cell/table creation
has already been completed, so there is no more need to
jump over any dummy paragraphs, even for the first table.
Affected unit tests were
- table-start-2-sdt.docx
- sdt-company-multipara.docx
- paragraph-sdt.docx
make CppunitTest_sw_ooxmlfieldexport CPPUNIT_TEST_NAME=testParagraphSdt
make CppunitTest_sw_ooxmlfieldexport \
CPPUNIT_TEST_NAME=testTdf158661_blockSDT
Change-Id: I4a8359cec27f88f6a2fc0464aa240b523a279e42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170920
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
* Update translations from branch 'master'
to d3e4d5213d29f57c45e2199822f2a68df9a884f6
- update translations for 24.8.0 rc2
and force-fix errors using pocheck
Change-Id: If72ef1ab34b88547d6caa85763242e8f2a231015
Instead of duplicating the same code in both,
`QtGraphics::GetResolution` and
`QtSvpGraphics::GetResolution`, create a static
helper method `QtGraphicsBase::ImplGetResolution`
in their base class and call that.
While at it, also move `QtGraphics::GetResolution`
to the source file where all of the other
`QtGraphics` methods are implemented.
Change-Id: I721459e8b65756f214fee77ac4d3cb8e500f0b57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170930
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Include X.509 certificates under Tools->Options->UserData
among the keys for signing.
Add a new checkbox to Save file dialog, to sign with that
selected key easily.
The checkbox is disabled if there's no matching key found.
Change-Id: I9fc16790c479819cd1f35bcad040d0ebc7c4bdef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170619
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
Don't modify the bound rect of tab items used used e.g.
for drawing the focus/selection/mouse-hover rectangles/indicators
in order to center the content horizontally and vertically.
Making the bound rect smaller in vertical direction
in `SvxIconChoiceCtrl_Impl::Center` resulted in margins
between entries for the non-native drawing path (e.g. the
gen VCL plugin on Linux) for the text-only case
(e.g. "Format" -> "Page Style" dialog in Writer).
Making sure that the content is centered should rather
happen in the drawing routine.
Horizontally centering already happens for the icon-case
anyway, as the `PAINTFLAG_VER_CENTERED` gets passed as flag
to the `PaintItem` call for the `WB_ICON` case in
`SvxIconChoiceCtrl_Impl::PaintEntry` anyway.
And for text-only mode, which was apparently the only one
for which centering vertically in `SvxIconChoiceCtrl_Impl::Center`
had an effect, vertically drawing text was implemented in the drawing
code path in
commit 180f0c1ec8
Author: Rafael Lima <rafael.palma.lima@gmail.com>
Date: Tue Jul 16 20:52:28 2024 +0200
tdf#161501 Improve visuals of selected entries in Vertical tabs
. This commit addresses the
> For the gen VCL plugin, there's still a small gap between
> text-only items (e.g. in the "Format" -> "Page Style" dialog
> which has a different cause and will be addressed in a separate
> commit.
aspect mentioned in earlier commit
Change-Id: Iac34098ef8d0f90f1ac0844df63839a6a99b83a7
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jul 22 11:39:48 2024 +0200
tdf#161501 icon choice ctrl: Drop extra space between items
Change-Id: I2077efc8ce1e97d52cf078d63bb4e4b528e389eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170895
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
`SvxIconChoiceCtrlEntry` has two members for maintaining
the bound rect:
* `aRect`, used almost everywhere
* `aGridRect`, used very rarely
`SvxIconChoiceCtrl_Impl::FindBoundingRect` calculates
a new bounding rect and assigns it to `pEntry->aGridRect`,
then calls `SvxIconChoiceCtrl_Impl::Center`, which
at first assigns the same value to `pEntry->aRect`,
so both are the same there.
The other place using the `aGridRect` member is
`SvxIconChoiceCtrl_Impl::CalcMaxTextRect` where
it's used as a fallback if `aRect` has not been
assigned a proper value yet.
However, since `aGridRect` is never assigned a
useful value apart from `aRect`, there doesn't
seem to be much value in doing that, so use
`aRect` there, too, and drop the `aGridRect`
member altogether and assign directly to `aRect` in
`SvxIconChoiceCtrl_Impl::FindBoundingRect` instead.
Instead of falling back to `aGridRect` in
`SvxIconChoiceCtrl_Impl::CalcMaxTextRect`,
add an assert that `aRect` is valid instead,
which never triggered in my tests with the
"Insert" -> "Hyperlink" and "Format" -> "Page Style"
dialogs, so should presumably be fine already.
Change-Id: I99f368672523279f530b937a73c3afb655f7853e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170894
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Unused since:
Change-Id: If309f84fcd9a99337bc5896ce5c3238333427da5
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Jul 23 11:00:42 2024 +0200
tdf#161501 icon choice ctrl: Drop debug-only mode switch feature
Drop code that allows switching the text mode of
the currently selected tab item in a vertical tab
bar using Shift+F10 or Ctrl+F10, which is only
available in dbgutil builds, and was therefore
likely meant to be used for debugging purposes
only.
As related code will be changed in a follow-up
commit, this would have to be adjusted to keep
it working. Instead of spending time on that,
just drop it. Testing how using another mode is still
possible e.g. by locally changing the value assigned
to `SvxIconChoiceCtrlEntry::eTextMode` in the
`SvxIconChoiceCtrlEntry` ctor instead.
Change-Id: If309f84fcd9a99337bc5896ce5c3238333427da5
Change-Id: I418fbf862ec94b04dbcfa4e7ff30cd5a8f9100e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170893
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Drop code that allows switching the text mode of
the currently selected tab item in a vertical tab
bar using Shift+F10 or Ctrl+F10, which is only
available in dbgutil builds, and was therefore
likely meant to be used for debugging purposes
only.
As related code will be changed in a follow-up
commit, this would have to be adjusted to keep
it working. Instead of spending time on that,
just drop it. Testing how using another mode is still
possible e.g. by locally changing the value assigned
to `SvxIconChoiceCtrlEntry::eTextMode` in the
`SvxIconChoiceCtrlEntry` ctor instead.
Change-Id: If309f84fcd9a99337bc5896ce5c3238333427da5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170892
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop the extra spacing between vertical tab bar items, which
became quite noticeable as extra white area between the otherwise
light-grey entries when using the Breeze (light) style and the
kf5 VCL plugin for the "Insert" -> "Hyperlink" dialog now that
the tab items are drawn natively since
Change-Id: Ie0c8ba1b56f6bb76ece6761253b93a109bb3a3f4
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jul 22 11:05:30 2024 +0200
tdf#161501 icon choice ctrl: Draw whole entry natively
and which is also more visible for non-natively drawn items
since
Change-Id: I578755a8a82ea811765b2e0dc3815fb47f67863c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Jul 23 10:41:16 2024 +0200
tdf#161501 icon choice ctrl: Draw selection within item bounds
With this in place, the extra margin between entries
in tab items with icons in the "Insert" -> "Hyperlink"
dialog in Writer is gone for both, the gen VCL plugin
and the kf5 one (tested with the Breeze style).
For the gen VCL plugin, there's still a small gap between
text-only items (e.g. in the "Format" -> "Page Style" dialog
which has a different cause and will be addressed in a separate
commit.
Change-Id: Iac34098ef8d0f90f1ac0844df63839a6a99b83a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170850
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In the same way that the calculated focus rect of an item
is used for drawing selection and focus indicators, use
it for mouse-hover highlighting as well, instead of
drawing a rectangle that reaches beyond the bounds
of the item itself for the non-native drawing path
of vertical tab bar items.
With this in place, hovering over an entry other than
the selected/focused one now shows a rectangle of the same
size as that for the focused entry, which is more
consistent and also aligns this with the case
where the native drawing API for drawing the item is used,
e.g. on Windows or with the kf5 VCL plugin on Linux.
This also means that a small gap can now be seen
between selected item and mouse-hovered item when
hovering over an item next to the currently selected
one for the gen VCL plugin as well, just as was
already the case before for the kf5 VCL plugin.
(Dropping that extra margin will happen in a
separate commit.)
Change-Id: I578755a8a82ea811765b2e0dc3815fb47f67863c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170891
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In `SvxIconChoiceCtrl_Impl::MakeEntryVisible`, always use
the bound rect as the area to make visible.
I see no reason to not do so when an entry is clicked
(s `SvxIconChoiceCtrl_Impl::MouseButtonDown`, which is
the only case that didn't do it yet.
Drop the `bBound` param accordingly.
Change-Id: I7a96e97585521943e7171c278fbd3509037cb7d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170849
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When native drawing of tab items is supported,
natively draw the whole (vertical) tab item (except for the
text) in `SvxIconChoiceCtrl_Impl::PaintEntry`,
instead of using native drawing API only for highlighting
the mouse-hovered entry, as originally introduced in
commit 8708e8cf90
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 11 10:47:50 2024 +0200
tdf#161026 tdf#161355 tdf#161501 icon choice ctrl: Natively draw mouse-hover
... feedback.
Set the corresponding state flags for selected and
focused entry, so that the native drawing routine
can take care of drawing the selected/focused
entry accordingly instead of using the native drawing
API to draw a `ControlType::WindowBackground` for that
purpose.
With this commit in place, all entries (not just the
mouse-hovered, focused or selected) entry are now
drawn using the native drawing API.
For the kf5 VCL plugin with the Breeze style, this
makes them look similar to the entries for the
non-vertical tabbar used elsewhere in LibreOffice,
or actual native `QTabBar`s.
Due to
Change-Id: Idf1e41d3bc309d152a4a36d14e8617bd6429940c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jul 22 08:25:32 2024 +0200
tdf#161501 vcl: Make TabitemValue position-aware
, the selection indicator is drawn vertically as expected
when using the Breeze style.
Restrict manually drawing entries (including focus
and selection indicator) to the case where native drawing
is not implemented (e.g. the gen VCL plugin).
Further tweaking the visual appearance (e.g.
getting rid of extra white margins and space between the
entries for the variant where icons are used,
like the "Insert" -> "Hyperlink" dialog in Writer) can be
done in separate commits.
Change-Id: Ie0c8ba1b56f6bb76ece6761253b93a109bb3a3f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170847
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Merge `SetBoundingRect_Impl` into
`SvxIconChoiceCtrl_Impl::FindBoundingRect` as that is the
only caller.
`SvxIconChoiceCtrl_Impl::SetBoundingRect_Impl` was ignoring
the bounding size being passed.
To be sure, still call `CalcBoundingSize` at the beginning
even though the return value itself is not used,
as the call to `SvxIconChoiceCtrl_Impl::CalcBoundingHeight`
that it does can result in class members like
`nMaxBoundHeight` getting updated.
Change-Id: I53b70bb8ddbf53afd9f95c38ce3dd05922e1110c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170846
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The method doesn't do anything for `bSelected = true`,
so drop the param, and only call it for the `bSelected = false`
case in `SvxIconChoiceCtrl_Impl::PaintEntry` instead.
Change-Id: I5e180a42f2960531d16e5df35ce0a4e9c63a1f91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170845
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
No need to have a `bSolidTextRect` variable here,
just do the relevant call right away.
That also means that there's no need to save
and restore the previous fill color for the
`bSelected = true` case (it never gets changed),
so move that into the if block as well.
Change-Id: I57637e570b01e2a09708fc7776c867817a131d31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170844
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
