The member is initialized to false in the ctor
and that value is never changed afterwards.
Drop it altogether and simplify code accordingly.
Change-Id: I0213e9f74b353a214af3ad163a934bfa7e868412
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211913
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
TableDesignWidget::m_bModal has a default value of false,
so there is no need to explicitly call TableDesignWidget::setModal
with the same value.
An upcoming commit will drop TableDesignWidget::m_bModal
altogether.
Change-Id: Iedfcc446b1c6f8d77d82d0478ff447590648765a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211912
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Port the toolbar popup to select the slide layout to use
from using two ValueSet widgets to using weld::IconView
instead.
This helps to be more consistent with other platform/toolkit
widgets and reduces custom widget logic.
Adjust indices used to account for the fact that
weld::IconView indices are 0-based while the ValueSet ones
are 1-based. For the particular case here, custom non-continguous
item IDs were used for the ValueSet items that
correspond to the AutoLayout enum values.
Store those custom IDs as the IDs of the weld::IconView items and
retrieve the ID again in LayoutToolbarMenu::IconViewItemActivatedHdl.
The popup can be triggered like this:
* start Impress
* in the toolbar, click on the "Slide Layout" button
Change-Id: Ib4bf1c611663e8001a6ffcff6bc5ecf393c22277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211908
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Without this in place, the following assert
would be triggered when closing the dialog:
soffice.bin: /home/michi/development/git/libreoffice/include/vcl/vclptr.hxx:134: VclPtr<SfxAbstractTabDialog>::~VclPtr() [reference_type = SfxAbstractTabDialog]: Assertion `(!m_rInnerRef.get() || m_rInnerRef->isDisposed() || m_rInnerRef->getRefCount() > 1) && "someone forgot to call dispose()"' failed.
Steps to reproduce:
* start Draw
* make sure the "Text" toolbar is enabled in "View" -> "Toolbars" -> "Text"
* in that "Text" toolbar, select the "Callouts" shape and insert it into the document
* right-click on the newly inserted shape to open the context menu
* activate the "Position and Size" menu entry to open the dialog
* press the "OK" button to close the dialog again
Change-Id: I2ddf9b6b0997db091ff8bc320ae04fbbfee19415
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211879
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
When an empty PPTX presentation was opened and saved,
its Title and Content layout/master slide lost its
autofit setting.
Original slide master had <a:normAutofit/> element
in its placeholders, which turned into <a:noAutofit/>.
This happened, because on import the inherited property
got overwritten by the default no autofit.
Change-Id: If9842d4c53eb283b9497b46198aaea4911413bc9
Signed-off-by: Aron Budea <aron.budea@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/14276
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit afe4932986453513ea1a50b1143de3827f39c0ed)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211865
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The expected numbers are what PowerPoint for Windows shows.
The tests cover: the same startAt on every paragraph, a new startAt
or numbering type, plain and unnumbered paragraphs between items,
nested lists, and startAt from a:lstStyle.
Change-Id: I75d9bfc88ca2e1d73442b28fb039c20fc1f907be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211783
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
It was added in
commit de3898aecb
Author: Stephan Bergmann <sbergman@redhat.com>
Date: Sat Jan 22 10:56:15 2022 +0100
Add missing test dependency
> [_RUN_____] SdOOXMLExportTest3::testTdf140912_PicturePlaceholder
but now testTdf140912_PicturePlaceholder lives in
CppunitTest_sd_export_tests-ooxml4 after
commit 8d6f1a6448
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Mon Oct 30 17:21:05 2023 +0100
CppunitTest_sd_export_tests-ooxml3: split in two
Change-Id: I840829973cf2e55929b4ca3cba86b1d81031a582
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211824
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Until now the 'local' StyleSheet got set, but that may
not be the same as the original. It was/gets identified just
by searching by name and type, not comparing content.
What to do? We could...
(a) the Style-Friendly way:
- check if StyleSheet is identical
- if not, create a new in-between StyleSheet hosting missing Items
- if yes, use, done.
(b) the pragmatic/practical way:
- Just hard-attribute the Items that are detected as different
similar to what BurnInStyleSheetAttributes does/did, but only
for a view differing Items
(b) is the most simple for now, but will lead to more hard
attributes. The other possibilities will be better in the
long term. For now, I will use (b).
Note that there are more cases in that VERY complex and grown
stuff emerging from SdDrawDocument::PasteBookmarkAsPage. More
things will need to be fixed, see this as a 1st step.
Needed to adapt postProcessAfterCloneToDifferentModel due to
UT testTdf96206 failing, see comment there for details.
That 1st implementation showed weaknesses with those Items
critical and only on MasterPages, so decided to give up on
that and implement ContentCompare to SdPage::Equals. That
was easier than thought: No parameter needed, only used by
InsertBookmarkAsPage_FindDuplicateLayouts::operator(). Thus,
SdPage::Equals needs no change, just SdrObject::Equals.
Due to still problems with Items corrected in Objects on
MasterPages I will for now exclude this.
Could now isolate remaining problems, these are defaults
and/or PresObj things on MasterPages. Important is that I can
completely correct all Items for all Objects in
postProcessAfterCloneToDifferentModel. I can react to these
false-positives in the ContentCompare in SdrObject::Equals.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I10e17c8d6a893dbe92ab716182f07bafce1f3284
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6595
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit 92ffaeac04c5c8586006b026f29ce12fba3674f1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211729
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Whatever SdDrawDocument::renameObjectStylesIfNeeded is
intended to do, it changes the look of SdrObjects when
doing what it does.
I am not sure if these are just the 'wrong' StyleSheets
that got copied or something else. It may happen when
slides from more than two sources get copied to a
document: The newly imported styles get 'extended' names
following a naming scheme. When pasting from a 2nd
document, the *same* names for slides get created using
that naming scheme, so before these were re-used here
assuming they have the same content - which is wrong.
To just *ensure* that the objects look will not change,
compare previous ItemValues with those ItemValues after
changing the style, that guarantees equal look - for the
cost of some more hard-set attributes, but less
StyleSheets.
I see that these corrections *are* done, so that is a
clear hint that re-setting these Styles in this whole
import has basic errors, I have to correct the values.
Also use a SdrObjListIter, the version before *only*
visited all SdrObjects plain on SdrPage, leaving all
GroupContent out.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I0cf1f823bddcea0b0087244268d1dc224da39638
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6449
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 605790cb198686d382c809de949094755e70e833)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208432
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
There is a bug where, an impress comment does not close when clicking outside of it.
More precisely, the comment does close, but is immediately opened again.
(Qt/gen)specific bug, not reproducible with GTK
The issue is caused by the handling of NotifyEventType::MOUSEBUTTONDOWN: it triggers
FloatingWindow::EndPopupMode(). However, when NotifyEventType::MOUSEBUTTONUP
is received, the call chain eventually reaches FuSelection::MouseButtonUp(),
which accesses an SdrObject from the SdrMarkList (GetMarkedObjectList()).
At that point, the list still contains the popup that is supposed to
be opened, so the comment gets opened again.
Change-Id: Ieb5691812009059d2100976932c34876cca5bc4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211275
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Exchanging the master page already updates all slides using the same
master, so it is enough to update one selected slide per master.
Change-Id: I1a76d20c33151c30679f5b11d179ffb2052e9438
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211580
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Regression after commit b41a780d139ec6ca5a5514db972ccf0e50058dfc (tdf#166401:
support custom placeholder prompt text, 2026-08-17), where a placeholder that
authored no prompt stopped writing text and got a bare <a:p/> instead.
On a slide an empty presentation object reports no text through UNO anyway, so
the paragraph the export wrote for such a placeholder never had a run. It
carried the properties, and those are the formatting. In PowerPoint 2016 the
original title showed white at 22pt, indented 56.5pt; the round-tripped one
showed bold black at 17pt, indented 18pt.
Write the paragraph the way a shape with no text already does: the paragraph
properties, the run properties in endParaRPr, and no run. The prompt still
stays out of the file. That branch of DrawingML::WriteText is now a method of
its own, called from both places.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I034a4e14f388c90872069d32b303c6c143c1814c
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10768
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit e2859f5b23f53281d80cbad4c56db1764aaf1406)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211538
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A PDF opened in Draw fills every page with a single imported image,
so the text boundary guides carry no meaning there. Drawing the page
background as transparent recently let those guides show through,
where the opaque background used to hide them.
Skip the guides whenever the document is a PDF, no matter what the
"show boundary for margins" setting says. Ordinary Draw documents
still follow the setting. The flag is recomputed on every redraw in
DrawView::CompleteRedraw, so the PDF exclusion goes there.
Add a test that renders a PDF page and checks the inner page border
is not drawn in the boundary color.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia2ea9116ef0a32ef0fb78cd35d926f668fa78705
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4812
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 5fa4bf9c49fb1416f005607c72b904388fc7170a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209434
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A PPTX shape keeps the fit the file was saved with until its text is
edited, and after that it is fitted by our own rules.
The fontScale and lnSpcReduction of a normAutofit never reached the
shape, for three reasons.
Import passed fractions to the TextFitToSizeFontScale and
TextFitToSizeSpacingScale properties, which are percentages.
A missing lnSpcReduction was read as 100000, a full reduction,
instead of 0.
When both properties were set in one setPropertyValues call along
with TextFitToSize, the collected fit item was applied last and
overwrote the scales.
Change-Id: I6b7fcfb6a1822f289f18b8ce77e78526a80f8944
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13539
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit c6938c35aa527883e2fd867f36e22c396601d376)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211506
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Steps to reproduce:
1) Write a formula with a color command, such as color red { 1 }.
2) Save the document as DOCX and open it again.
The formula comes back at the default color, and the color command has
gone from its text.
A run is one stretch of text with a single set of formatting. In a
formula each run carries two property elements. The import already read
the math element m:rPr. The font color sits in the text element w:rPr.
The import skipped that one as an unexpected tag, and the export never
wrote it.
Read w:color on import and put a color command around the text of that
run. A color that StarMath has a name for is written with that name, so
a formula written as color red reads the same way after a round trip.
Other colors become hexadecimal digits, which the parser reads only in
upper case. A value of auto leaves the default color in place, and so
does black, which keeps ordinary formulas clean and lets the color
follow a dark document theme.
The braces of a color command hold an expression, and a run holds
whatever text the document put in it. A run of operators is written as a
literal, which is an expression and keeps the color. A run that does not
parse for any other reason keeps no color command, so the formula reads
the way it did before any color was carried over. The import never
writes command text that fails to parse.
On export, write w:color for a run whose node has a color of its own, but
only for a DOCX. A slide or a sheet never declares the w namespace, so the
color stays out of a presentation or a spreadsheet. The tree has been
arranged by then, so a surrounding color command has already reached the
leaf nodes.
The color of the lines and signs a formula draws, such as a fraction
bar, travels elsewhere and is not covered here.
Added the testMathColor and testMathObjectColorOmittedInSlide unit tests.
Signed-off-by: Bayram Çiçek <bayram.cicek@collabora.com>
Change-Id: I4207aab6a363e5f841de58e3f743d9e010609c10
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10046
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit dfcc0c42df5c774f4087f425cad0af81ecea6b5e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211415
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Similar to previous commit
Change-Id: I5db3a99bb8d78099e3b136cbcd402fe2ae49d49c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Sat Sep 19 13:12:54 2026 +0200
[API CHANGE] Pass XAccessible to XAccessibleGroupPosition::getGroupPosition
, also pass an XAccessible instead of a uno::Any to
XAccessibleGroupPosition::getObjectLink.
See the above-mentioned commit for more background.
Change-Id: I8440b91eff66a18bc6e431a0ad91362e895d945c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211217
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Instead of passing an XAccessibleContext wrapped in a uno::Any,
pass the XAccessible. This drops an extra level of
wrapping/unwrapping.
The same will be done for XAccessibleGroupPosition::getObjectLink
in an upcoming commit.
Since the XAccessibleGroupPosition interface
(and the UNO a11y API in general) is unpublished
and meant for internal use only, changing it should
be unproblematic.
Change-Id: I5db3a99bb8d78099e3b136cbcd402fe2ae49d49c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211216
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the more concrete OAccessible instead of the abstract XAccessible
UNO interface for that member.
Drop now unnecessary querying for the XAccessibleContext UNO
interface, as OAccessible implements that interface itself
as well.
Change-Id: I689af3c6b72f442967ab7fe4c39d438fc68b09fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211215
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the more concrete OAccessible for the parent param
instead of the abstract XAccessible UNO interface, to
make clear that the parent is always an OAccessible subclass.
Change-Id: I6447f6131e809baddc24a4b413fe4d4748aa7a7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211214
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Use the more concrete OAccessible instead of the
abstract XAccessible UNO interface for that member.
Change-Id: Id811da24db3e48baefa22343d999541cd31546af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211213
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Use the concrete known type for the local var instead
of the abstract XAccessible UNO interface in
AccessibleSlideSorterView::getSelectedAccessibleChild.
Change-Id: I7253df538dd0aa2e9003575a33b4572353e852b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211182
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the concrete known type for the local var instead of the
abstract UNO XAccessible interface.
Change-Id: I2dfb9f5367d45bed768097f4be73182a2defc598
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211181
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Return the result right away instead of first assigning
it to a local XAccessible variable.
Change-Id: I3451890a155c7791ec6f08cada34f3fbbc317ea3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211180
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Return an rtl::Reference in AccessibleSlideSorterView::Implementation::GetAccessibleChild
and related methods instead of a plain pointer.
Change-Id: I7ecf8c21ca8220408d1633aa2243fdbda987aadb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211179
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Switch param for parent param in the ctor from the abstract
XAccessible UNO interface to the more concrete OAccessible.
Change-Id: Id34208c539c45807fc8f957e565df2b0d833acff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210676
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Qt plugin automatically orders buttons for each platform based on
the button's role, which we derive from the Gtk .ui file's
action-widget response code. But to do that conversion from response
code to Qt button role, we need a standard response.
Without a standard response, the button has no role, and gets ordered
to the right of OK/Cancel buttons on Mac. With the correct role, it
is correctly placed far-left along with the Help button.
Change-Id: I16d3126d4999649e7aa6e72ec5e7b1a25f48c2a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210223
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
The default drawing style names a theme color now, and a PPTX saved
to ODF and back came out with every shape green. A shape that really
did name a theme color lost the reference and came back plain.
A color item holds the color and the theme reference together.
Setting a plain color started from the item the shape inherits from
its style and overwrote the color alone, so the inherited reference
won. Clear the reference, which is what an explicit color means.
The ODF export repeats each shape's fill on a paragraph style,
applied after the graphic style, and the paragraph properties had no
complex color. Carry it there too.
A style's graphic properties took a complex color only when it was
the character one, matched by element name. Match on the context id,
which the fill and stroke colors share.
Add a round trip test through ODF and PPTX with a plain shape, a
themed one, and a themed one with a luminance modulation.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia9550222d18a243287240e4184666d78d0abdd22
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10060
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 07cf37b104983f765d3e1005f677e0058df12026)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210510
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
as part of the process of merging the Outliner code into the normal EditEngine paths.
So instead of keeping a bunch of information "on the side" and then having to merge information
from multiple sources, it all lives where it logically belongs.
Also take the chance to rename the depth/getdepth/setdepth
fields and methods to NumberingDepth, which makes the purpose
more obvious.
Change-Id: I314673ee1b9efa14f178ac34a122995a554cd788
Signed-off-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10551
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 284bbe0af12b96844976f30bb35ade3a327ea76d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210503
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The com.sun.star.accessibility.AccessibleContext UNO service
is unnecessary and not really used for implementing a11y support,
apart from some a11y implementations declaring support for it.
What is relevant is the com.sun.star.accessibility.XAccessibleContext
interface instead.
Stop declaring support for the com.sun.star.accessibility.AccessibleContext
service in AccessibleContextBase and drop related
XServiceInfo::getImplementationName overrides in subclasses,
in preparation of dropping the service altogether in an upcoming
commit.
AccessibleDrawDocumentView currently still declares support
for the "com.sun.star.drawing.AccessibleDrawDocumentView"
service, so let it implement XServiceInfo directly, now that
it no longer inherits that from the AccessibleContextBase
base class.
Change-Id: Ie927cd98f9e1c8eb5a80bfaab5cb1dacb64dc238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210403
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The com.sun.star.accessibility.AccessibleContext UNO service
is unnecessary and not really used for implementing a11y support,
apart from some a11y implementations declaring support for it.
What is relevant is the com.sun.star.accessibility.XAccessibleContext
interface instead.
Stop declaring support for the com.sun.star.accessibility.AccessibleContext
service in AccessibleSlideSorterView, in preparation
of dropping the service altogether in an upcoming
commit.
Change-Id: Ie37eacfa7725abd550cb39d7ce3ad53893640c88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210398
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This AccessibleContextBase::getAccessibleParent override
calls `ensureAlive()` before calling the base class implementation.
However, the base class implementation already calls that at the
beginning as well, so the override is redundant/unnecessary. Drop it.
Change-Id: I5a3c6756e237903923e2ee5e8e4ac7bed3e54ee8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210380
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Pass the more concrete OAccessible instead of the abstract
XAccessible UNO interface for the parent param to the
AccessibleDocumentViewBase ctor.
Change-Id: I7bc782f2d6f9b2debd49230cd07eff5013a0be9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210379
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Pass the more concrete OAccessible instead of the abstract
XAccessible UNO interface for the parent param to the
AccessibleDrawDocumentView ctor.
Change-Id: I68fe5e93e131a44f8e9d794ad73161353ab634cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210378
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Michael Weghorn