Instead, leave the cursor in the text at the paste location, like
(reportedly) some version of Word does.
This can be configured with the new
Office::Writer::Cursor::Option::SelectPastedAnchoredObject
Change-Id: Id1ddeb0e17c5cd568100d5a8169d929487d16749
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189001
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
The
GetRangeFromCalc(filename: str, range: str)
method (stored in the Session service)
reads the values contained in the given
range located in the given Calc file.
The file does not need to be open. This
makes this shortcut particularly useful.
The content of the range is returned either
- as a scalar for a single cell
- as a 1D-array or a tuple when the range
is contained in a single row or column
- as a 2D-array or a tuple of tuples for
a rectangular range of adjacent cells.
Clean error management is included in the code.
The method is available for Basic and Python
user scripts.
The user documentation needs to be updated.
Change-Id: I39cd218f0bf3a6a21e3ada42826069eeee451c6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189000
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
and
cid#1659673 Variable copied when it could be moved
cid#1659676 Variable copied when it could be moved
cid#1659677 Variable copied when it could be moved
cid#1659680 Variable copied when it could be moved
cid#1659681 Variable copied when it could be moved
cid#1659684 Variable copied when it could be moved
Change-Id: I2f56bef35f6a0a4acdfee13348f1b56c16a345f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188997
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1660184 Variable copied when it could be moved
cid#1660183 Variable copied when it could be moved
cid#1660182 Variable copied when it could be moved
cid#1660181 Variable copied when it could be moved
cid#1660177 Variable copied when it could be moved
cid#1660176 Variable copied when it could be moved
Change-Id: Id5c90c0a0d4a0a86ef0f4b513b45c2db3a97b207
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188975
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Otherwise, running the embindtest code in a LOKit-based scenario (analogously to
how it is run under certain circumstances via
--post-js $(SRCDIR)/unotest/source/embindtest/embindtest.js
in desktop/Executable_soffice_bin.mk) would cause a deadlock when
TestThread::execute (in unotest/source/embindtest/embindtest.cxx) calls
SolarMutexGuard g;
on that additional thread, but the main thread never released the SolarMutex
because of that acquire in lo_runLoop.
The code in lo_runLoop had originally been added with
b693fb5cf1 "We apparently need to drop the Solar
Mutex when exiting lo_runLoop() on iOS" (curiously using explicit calls to
acquire and release, instead of using an additional SolarMutexGuard; the
difference being that a SolarMutexGuard would automatically be released upon an
exception, which skips the explicit call to release), originally only for iOS,
then extended to Android with 0abdf307ea "android:
Unregistering in runLoop() is important even on Android", then extended to
Emscripten with 1e421b30e2 "Attempt to add ifdefs
for WASM (Emscripten) for LOKit-based code" for no apparent reason.
I have no idea how the Android and iOS scenarios are meant to cope with
soffice_main being called with SolarMutex being acquired twice, so that no other
threads could ever acquire it (except thanks to temporary uses of
SolarMutexReleaser, which might explain things).
However, what happens in the Emscripten scenario is that executing soffice_main
leads to a call to emscripten_set_main_loop_arg in SvpSalInstance::DoExecute
(vcl/headless/svpinst.cxx), which quits by throwing an exception all the way to
the JS event loop, so that in lo_runLoop the inner SolarMutexGuard automatically
gets released, while the outer explicit call to release got skipped, leaving the
SolarMutex locked forever on the main thread.
As there is no apparent reason why the Emscripten scenario should have this
double locking here (and the call to vcl::lok::unregisterPollCallbacks at the
bottom of lo_runLoop would never be executed in the Emscripten scenario, anyway,
thanks to the exception being thrown from emscripten_set_main_loop_arg), and
1e421b30e2 "Attempt to add ifdefs for WASM
(Emscripten) for LOKit-based code" maybe just added it in a blind copy/paste,
lets just skip it.
(And add a DBG_TESTNOTSOLARMUTEX to the embindtest code, to document that code's
assumptions.)
Change-Id: Ibae0d1d8b5f29f08d30829251ed2bb58413ea4e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188973
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
This will e.g. be used by the "Tools" -> "AutoCorrect"
-> "AutoCorrect Options" dialog.
Change-Id: I22a1d2f894a4edb4d1c881ebe74c6176a581bf64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188947
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
`bOnlyExpanded` is always false since
commit 87e33c3c1c
Date: Tue Sep 1 17:11:08 2020 +0100
drop some unused methods
, so drop the param and merge the helper
function into the other
GtkInstanceTreeView::iter_next.
Change-Id: If0fea58eb0299f552a78d5241f647294664dbb49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188946
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Do it similar as the GtkInstanceTreeView implementation
does by reusing existing methods to get the first
iterator and iterate from there.
This depends on QtInstanceTreeView::iter_next to also
get implemented to actually be useful, would currently
assert there.
Change-Id: If7e20d5b1104ab66c1f3eba0574406d49a926b5e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188945
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This will e.g. be used by the "Tools" -> "AutoCorrect"
-> "AutoCorrect Options" dialog.
Change-Id: I8bcd8c584558900a99579af16572da714bcbdd61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188940
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
SpellDialog can't do all of its initialization in the
ctor because it needs to call virtual methods on the
SpellDialogChildWindow* that gets passed as a param,
but that one calls the SpellDialog from its ctor, i.e.
it hasn't been fully initialized yet.
For that reason, the part of the initialization done in
InitHdl was delayed by using a user event (posted via
Application::PostUserEvent).
This also includes setting the dialog title based on
the selected text language.
As a consequence of this, the title, and therefore the
accessible name of the dialog would change after it was
shown, which would result in Orca speech output for the
dialog getting interrupted (see tdf#163802).
Avoid the problem by not depending on the next user
event getting processed, but calling the method
that does the rest of the initialization manually
after the SpellDialogChildWindow constructor has
finished.
In order to do that, add a virtual SfxChildWindow::Initialize
(that does nothing) and override it in the
SpellDialogChildWindow subclass.
Since SpellDialog::Initialize (renamed from SpellDialog::InitHdl)
is now guaranteed to be called before the dialog shows
and that one always sets a title (by calling
UpdateBoxes_Impl), drop the no longer needed
// fdo#68794 set initial title for cases where no text has been processed
// yet to show its language attributes
OUString sTitle = rParent.HasGrammarChecking() ? m_sTitleSpellingGrammar : m_sTitleSpelling;
m_xDialog->set_title(m_xDialog->strip_mnemonic(sTitle.replaceFirst("$LANGUAGE ($LOCATION)", "")));
from the ctor.
Additional fix for GTK 3 to avoid incorrect
object:property-change:accessible-name events from
getting sent when the title didn't actually change [1]:
commit 0cc9e603f4635c31d2a8a5f602869474d329e728
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Aug 4 15:31:06 2025 +0200
a11y: Only notify when window title changed
In gtk_window_set_title_internal, return early
when called with the same title as is already set.
This also ensures that notifying of a change
of PROP_TITLE only happens when the property
actually changed, which also prevents invalid
object:property-change:accessible-name AT-SPI
events from getting emitted on the accessibility
layer when the title hasn't actually changed.
Fixes: #7690
Part-of: <https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8814>
Output of the pyatspi listener script from tdf#163802,
attachment 197494 for gtk3 before this LO commit (note the
object:property-change:accessible-name event after
the object:state-changed:showing event):
event type: object:property-change:accessible-name, event source: Spelling: , states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:property-change:accessible-name(0, 0, Spelling: )
source: [dialog | Spelling: ]
host_application: [application | soffice]
sender: [application | soffice]
event type: object:state-changed:showing, event source: Spelling: , states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:state-changed:showing(1, 0, 0)
source: [dialog | Spelling: ]
host_application: [application | soffice]
sender: [application | soffice]
event type: object:property-change:accessible-name, event source: Spelling: English (UK), states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:property-change:accessible-name(0, 0, Spelling: English (UK))
source: [dialog | Spelling: English (UK)]
host_application: [application | soffice]
sender: [application | soffice]
Output with this change in place:
event type: object:property-change:accessible-name, event source: Spelling: English (UK), states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:property-change:accessible-name(0, 0, Spelling: English (UK))
source: [dialog | Spelling: English (UK)]
host_application: [application | soffice]
sender: [application | soffice]
event type: object:state-changed:showing, event source: Spelling: English (UK), states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE']
object:state-changed:showing(1, 0, 0)
source: [dialog | Spelling: English (UK)]
host_application: [application | soffice]
sender: [application | soffice]
[1] https://gitlab.gnome.org/GNOME/gtk/-/commit/0cc9e603f4635c31d2a8a5f602869474d329e728
Change-Id: I6cdfe8443ae435e1e644b78942cf63e9df1d400f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This is also to make a bit more obvious what part of the
initialization happens in the ctor and what only
happens later:
The (similarly named) SpellDialog::InitHdl
only gets called later. (And the logic for the latter
will change and it will be renamed to
SpellDialog::Initialize in an upcoming commit.)
Change-Id: Ia2647eddb15163f92c10b0ae9396b54895a38192
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the order in which the widgets in the .ui file
are defined so that the order matches the visual appearance
and logical order, which makes sure that tab focus order with the
Qt-based VCL plugins is correct as well when using native Qt
widgets (SAL_VCL_QT_USE_WELDED_WIDGETS=1), where
focus order is (by default) based on widget creation order.
See
commit 02692566ad
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Oct 24 17:43:35 2024 +0200
tdf#130857 optnewdictionarydialog.ui: Define focusable widgets in order
for more background.
The dialog can be triggered as follows:
* start Writer
* type some random text
* "Tools" -> "Spelling"
The dialog is not yet declared as supported for use with
native Qt widgets, but in a WIP branch it makes moving
focus with the Tab key work as expected.
Change-Id: I3a8d750a543deeab45ee0085088f4f90f32307a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188938
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
and
cid#1660211 Variable copied when it could be moved
cid#1660204 Variable copied when it could be moved
cid#1660195 Variable copied when it could be moved
cid#1660194 Variable copied when it could be moved
cid#1660193 Variable copied when it could be moved
cid#1660191 Variable copied when it could be moved
cid#1660188 Variable copied when it could be moved
cid#1660187 Variable copied when it could be moved
Change-Id: Ifcb179f73723e2d43144e242fa9c1b5ac332cd4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188965
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1660297 Variable copied when it could be moved
cid#1660225 Variable copied when it could be moved
cid#1660221 Variable copied when it could be moved
Change-Id: I3b0d8a60b216339b0220ff80255e5d24882d8f1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188964
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Have now found a way to also change ImpEditEngine::
DrawText_ToEditView to work without StartPosition.
Thus adapted StripAllPortions accordingly, plus
logical follow-up changes where StartPosition/
Origin is not needed/Point(0, 0) used.
Change-Id: I1513778943705967752dddf8923012b66561e10a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188958
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
regression from
commit 088a7c7c45
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Tue Sep 24 16:18:11 2024 +0200
remove alpha device from OutputDevice
I am a little confused here. I would have thought kSrcOver would
be the right blend mode, but instead it is kSrcATop
which produces the "right" answer.
Change-Id: If5bfb0ab139cbed5acaba2cc66c5036ca091818c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188957
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel Grandin