Age | Commit message (Collapse) | Author |
|
The nCount object might go out of scope, as it's used by
an async function.
https://gerrit.libreoffice.org/c/core/+/164316/comments/507b830b_001a71eb
Change-Id: I4218f6e35b61704115047481cb97a193c593a072
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154750
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Added by mistake in b22039cff8380b158307e75762bd3e4ca045d77b
"related: tdf#159947: only parse in/result if the element supports them"
See https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/in
Change-Id: Ie8b5591349eff710d1edc7f413790ac9d31df99d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166389
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
...ever since the code was introduced in
0c7ae3bd96130eaa400d55a3ba9bf1e2fe6600de "tdf#156146 tdf#159903 sw: add unit
tests"
Change-Id: Ib53b98f6f1ce460bda6b06a7b082a28a49f05a28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166388
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
2411.71ms -> 2395.36ms
Change-Id: Ie6a3f281b56e827b77dddd1eb8ae6db9d2691c8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166387
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
... , OPoolCollection
However destruction is called when closing LO, not when just closing the file.
Change-Id: Iacb09b73de49b9635240d3b43e721b8b02d35afd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166370
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iec5327b6f0125b22a2a4ee8ccb789b5403a7fdb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166070
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib8bd453483c72382330b4c960cdbe735bdb97eac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166374
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
* Update helpcontent2 from branch 'master'
to 183a14d99cbf6b18fa7d3d059a2ff0639520a205
- tdf#152499 Help page for Select UI dialog
Help part
Change-Id: I3fa18868abed3b738b699a7abcc216aaa90df12d
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/166196
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
Core part
Change-Id: I6344c93b187ac0835faf13a06f02cd2a9fe0fcd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166195
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
Field Shading / .uno:Marks toggles now only fields, footnotes, tox etc.
and Tab, SoftHyphen, Blank, as well as ControlChar depends now on
Formatting Marks / .uno:ControlCodes. Field Shading also does not
toggle HardBlank and SoftHyphen, and what control character is shown
respect the options under Formatting Aids
Change-Id: I63c826e7fdc09ec95f17aee9735d4f5de9a1b897
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166033
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
Change-Id: I103574d720fef685b806943672a2aeb1fbf87097
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164316
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Previously, a custom BreakIterator was used for Thai grapheme clusters.
This change deletes the custom BreakIterator, in favor of the ICU
implementation.
Change-Id: Icec94c73a5734c2059786dfbba085f487c488d7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166156
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: Ie80487e20217d7a54cb401b0423dfec01df1292e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166373
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
See https://unicode.org/charts/PDF/U0080.pdf
Change-Id: I6bc3117abb486cc2cc38870ed91185c62eaa9361
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166243
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
Error was:
ld.lld: error: undefined symbol: LanguageTag::~LanguageTag()
>>> referenced by stl_construct.h:119 (/usr/lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/bits/stl_construct.h:119)
>>> core/workdir/CxxObject/sc/inc/pch/precompiled_vbaobj.o:(void std::_Construct<LocaleDataWrapper, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>&, LanguageTag const&>(LocaleDataWrapper*, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>&, LanguageTag const&))
>>> referenced by stl_construct.h:119 (/usr/lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/bits/stl_construct.h:119)
>>> core/workdir/CxxObject/sc/inc/pch/precompiled_vbaobj.o:(void std::_Construct<LocaleDataWrapper, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>&, LanguageTag const&>(LocaleDataWrapper*, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>&, LanguageTag const&))
>>> referenced by stl_construct.h:119 (/usr/lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/bits/stl_construct.h:119)
>>> core/workdir/CxxObject/sc/inc/pch/precompiled_vbaobj.o:(void std::_Construct<CharClass, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, LanguageTag const&>(CharClass*, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, LanguageTag const&))
>>> referenced 5 more times
Change-Id: Ie84d062d1815aa8e8118171862e0f8f64331d769
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166346
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
no interesting unit tests found, but this one at least lets you
add text to the body and visibly see the effect of foreground/background.
make CppunitTest_sw_ooxmlimport CPPUNIT_TEST_NAME=testN751077
Change-Id: Ib03e6b429ad4ec6a38d1119f3720bc56a70b98eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166345
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
|
|
Change-Id: I602b24eb624420549b0fde23e662db7700e23da0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166372
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
after double click on a drawing obect in the Navigator doesn't move to
the next/previous drawing object when there is a number rule at the
current current cursor position and the current cursor position is at
the start of a paragraph.
This patch reworks the SwWrtShell::GotoDrawingObject function so the
document cursor position gets moved to the position of the drawing
object when the object is selected.
Another way to get expected results is to leave the GotoDrawingObject
function as is and move:
else if (rSh.GetSelectionType() &
(SelectionType::Graphic |
SelectionType::Frame |
SelectionType::Ole |
SelectionType::DrawObject |
SelectionType::DbForm))
above the:
else if( rSh.GetNumRuleAtCurrCursorPos()
&& rSh.IsSttOfPara()
&& !rSh.HasReadonlySel() )
in the SwEditWin::KeyInput function case KEY_TAB: block.
SwWrtShell::GotoDrawingObject is made SW_DLLPUBIC by this patch to able
to be used by the included unit test.
Change-Id: I047b416ae94a9284d304798924e0c5f2be526f85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166089
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
Change-Id: If632bd8d503f5e8c9acdab912ac0bc8a00dfd534
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166308
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I824b8670f7f2d6409ae98fe1a107c6c430fc1bfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166371
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
As described in more detail in the previous commit
Change-Id: If5faf77c5f82836c376c04bb6e4e42ce5a3023a2
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Apr 18 14:02:25 2024 +0200
tdf#159910 gtk3 a11y: Keep a11y props for combobox
, the gtk3 VCL plugin uses a custom combobox implementation
rather than the stock GtkComboBox.
Similar to how the above commit makes sure that accessible
role, name and description set for the stock GtkComboBox
are also set in the custom implementation, do the same
for the accessible relations as well, by taking over
the relations from the GtkComboBox to the toggle
button of the custom implementation as well.
One particularly relevant relation in practice is
`ATK_RELATION_LABELLED_BY`, because the target set
via that relation is what screen readers tend to
announce when a combobox receives focus and doesn't
have an accessible name set for itself.
With this change in place, the Orca screen reader
announces the corresponding label e.g. in the
"Format" -> "Character" dialog in Writer, tab
"Font Effects", so e.g. "Overlining:, combobox"
is announced by Orca when the combobox for setting
the value for the overlining receives focus,
rather than just saying "combobox", which
wouldn't make clear to the user what this
combobox is for.
(This also matches what Orca already does for
the qt6 VCL plugin.)
This change only takes over the relations
set for the combobox itself. Usually, relations
are set both ways (e.g. the target of the
`ATK_RELATION_LABELLED_BY` relation would
itself have an `ATK_RELATION_LABEL_FOR`
relation with the combobox as a target).
If necessary, this solution could be
extended to also iterate over all the
target objects and check whether they
have relations with the combobox as a target
and set corresponding relations to the toggle
button as well (or instead).
Change-Id: I05e39ef5606ffa49ca7673039de3e1aa74fc8649
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166259
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Due to various issues with GtkComboBox, the gtk3 VCL
plugin does not use the original GtkComboBox, but a
custom implementation, originally
introduced in
commit bc0e0f633b05c4f91b6695488fc9e5c127507ba5
Date: Thu Apr 9 11:41:00 2020 +0100
tdf#131120 use a replacement for GtkComboBox
(See full commit message for more details and reasons.)
This means that the accessible role, name and description
from the .ui file are not set automatically for the
GtkToggleButton widget that acts as the combobox
instead and receives keyboard focus.
In order to make these available for AT, explicitly
take these over from the original GtkComboBox.
With this in place, the Orca screen reader now
e.g. properly announces the comboboxes in Writer's
Navigator as "Navigate By, combobox" and
"Active window, combobox" (similar to how it already
does for the qt6 VCL plugin), rather than just saying
"toggle button, not pressed", which didn't give any hint
to the user what the currently focused UI element
is about and how to interact with it.
Also set a default a11y role of combo-box in
the replacement's .ui file. (The role from
the GtkComboBox's AtkObject should always override
that in practice, though.)
Change-Id: If5faf77c5f82836c376c04bb6e4e42ce5a3023a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166248
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
... before doing more changes to the file in an upcoming
commit, to keep the diff clearer.
Change-Id: I3da5d9d708681888418251139e1d5aad4c152ad6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166247
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Set a11y name for this combobox in the Navigator to
"Navigate By".
This is in line with the tooltip shown when hovering over
the combobox, which is set for the combobox's parent,
the panel.
This makes Orca with the qt6 VCL plugin now announce
the a11y name of the combobox with the corresponding
role, rather than the panel
("Navigator, panel, Navigate By, combobox" instead of
"Navigator, panel, Navigate by, panel, combobox").
For gtk3, Orca still doesn't announce the combobox or
it's a11y name set in the .ui file, but still just says
"Toggle button, not pressed", which will have to be
addressed separately.
This is because while there is a combobox with accessible
name "Navigate By" in the AT-SPI tree now, the object
that gets focus is a toggle button that doesn't have
a name set for the gtk3 VCL plugin, which will be
addressed in a separate commit.
Change-Id: Id6b615f033c78d318611b520d49332714fa40eb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166246
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
when we know that the selection overlay consists purely of rectanges, we
can use a faster algorithm to generate the combined polygon
Change-Id: I15129facc6e682261fb59e79cf93b0e9d9e114b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165752
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I171639150a84372e7e25b5246d4882c467edd58b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166271
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
Previous code tried to hack some tricks to restore whitespaces after
trimming them according to the xml:space attribute value. But it was
wrong in multiple ways.
1. The collapsed space must stay in the block where its start was.
When a block ended with a space, then trimming the space from it,
and adding to a next block, can change the size of the space.
2. The shift of a line (e.g., specifying x and y values) doesn't end
the logical line. A space before such a shift must be kept by the
same rules, as if there weren't a shift.
3. A block with xml:space="preserve" is treated as if it consists of
all non-whitespace characters, even if its leading or trailing
characters are spaces. I.e., a trailing space in a block before,
or a leading space in a block after, should be collapsed into a
single space, not removed - even when the space-preserving block
itself is made invisible.
Change-Id: Ic778d1e9d6b9d0c342ea74ad78d44bb47bc8d708
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166239
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4963987a63d82dfe086932307675f92deebb8883
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166316
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(the types that are meant to be passed directly by pointer will need more
thought, to make them actually work)
Change-Id: Ia0f2e6f5335fad1140629477e89fc96121c2927e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166318
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
$equals was the last remaining special $... method that we added to the UNO
interfaces, and it looks better anyway to turn it into a symmetric free function
(that can be called with null for either argument) that is actually independent
of specific interface types
Change-Id: I22a1d08b8b15a0ed2dd37fa9fbc95f568641dec3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166317
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I23265f46b25cb88796267abe28aac1100523e71b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166298
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Id9ffa49ae61824ee155cd4b5373d882381b40db0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166288
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Change-Id: I3064195408e508f1f77d22b82ad464a651064193
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166287
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Opening an SVG with text in different elements (e.g., tspans) in the
same text element performs calculations to position the parts properly
(i.e., the next part will start where the previous part ended, unless
the position in overridden explicitly). These calculations require to
know the text widths. The first problem leas here: the text width was
calculated for a typically small text size (numerically equal to the
pixel size defined in the SVG), but these calculations aren't truly
linear, because font rendering may change depending on font height.
Additionally, the rounding gives much higher error in smaller sizes
than in larger. There was already a workaround for a similar problem
in ViewRedirector::createRedirectedPrimitive2DSequence, where a large
font (with 100 times greater height) was used to increase correctness.
This was also used here, with the same large height (50000) used as a
reference.
Then, at the time of wrawing the text at different zoom levels, the
code in VclProcessor2D::RenderTextSimpleOrDecoratedPortionPrimitive2D
creates a font of a calculated size, and uses it to output the text.
But the font is always created with an integral height, which means,
that for a wanted height of 2.5 (in a zoomed out view), the really
used height will be 3, which is 20% larger; or for wanted height of
2.4, the actual height will be 2 (20% smaller). This resulted in odd
jumps of the text widths, when the text may overlap the following
part, or conversely, create a big gap before the next gap. To try to
mitigate that, the function now takes the difference between the
wanted and the actual font size into account, and adjusts the MapMode
accordingly. This doesn't fix the jumping completely (e.g., because
of the mentioned special handling of small font sizes in the fonts
thenselves, like hinting), but still makes the calculations much more
stable, decreasing the amount of jumping. Similar changes are made in
TextLayouterDevice.
Use of the functions that return text size as a double, not rounded
value, should additionally help improving stability.
Change-Id: I455845d8ca43ee9c06a0fc980947f35d8a25797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166238
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The original issue that prevented the test on Linux is reproducible.
I didn't debug the cause, so this is just a workaround.
Change-Id: Ifa8fa2a7884adabf797ea2d711f62b6be382dfec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166351
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4943244d8c08d1d86e4c1ff9177b00cfa451e453
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166315
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibb4d4d1cca59ece6bcd28e887f84d657dedee756
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166314
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia1379762ba957097a1a2134c5d206f254e22683b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166313
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idf7d3abd464b7be87d109d14adf94357a5d49dd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166312
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia3e1b50954354973ffef701821f661cf782687db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166311
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4161adac7544e7b1a8a7d8e18a3ae6c72ca77062
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166310
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I82c4abc6883d292114b4239efee60aee082357fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166307
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
And introduce GetTextWidth / GetTextHeight variants returning double.
It allows to avoid premature rounding.
At least in one case - testTdf145111_anchor_in_Fontwork - it allowed
to make the test DPI-independent (at least in my testing on Windows,
using 125, 150, and 175% UI scaling).
Change-Id: I973d2c729ec6bb7114b4f99b9027f1ead7c1d061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166237
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
and flatten it a little
Change-Id: I3377f832658c504a2541c6994f7386adad06b0e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166321
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib122ad0fce8159c1ceb092bcc65a59ba1ad23bc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166174
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
|
|
I was concerned that I might override highlights
set in numbering.xml but in that case
pFormat && pFormat->hasItem(RES_CHRATR_HIGHLIGHT)
so pCleanSet no longer hasItem.
(see num3n.docx and TestDoc_highlight2.docx)
Note: must use Word 2010+ to see numbering.xml highlights!!
This is strictly a visual thing. Unit testing has traditionally
used magic tile rendering x,y positions to check the color,
which seems completely untrustworthy.
Change-Id: I026252f127107e4782d08f72bfd5e2a412142111
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166303
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
|
|
Ported two more SDK examples ChartInDraw and ChartInWriter from Java to
Python.
ChartInCalc and helper classes which contain additional helper methods
were ported in a previous patch.
Change-Id: Idffa0c07282dfc2c0f09ec5a9959f1db34a1d9a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165088
Tested-by: Jenkins
Tested-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Hossein <hossein@libreoffice.org>
|
|
speed up the matching of duplicates in CellAttributeHelper by using
std::set and partial sorting by name
Takes my time from 33s to 6s
Change-Id: I06376c1e253981cb5a3020142d24fa5776513d4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166262
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...which are needed at compile time (the emscripten::class_<T> ctor always
records the address of emscripten::internal::raw_destructor<T>, even in cases
where it never calls it; and raw_destructor internally calls delete, but the
dtor of the UNO interface types is protected) but not at runtime (as those UNO
interface types are only accessed through css::uno::Reference smart pointers)
Change-Id: I09e4f258f8dfc0fc53c0fe7210c7f709d86be176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166304
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
since we assign it from a temporary OString.
No idea why this hasn't caused a problem already.
Change-Id: I5480fb2ab5d1e07212ad804f99223946abf5a6c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166297
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|