CoinMPSolver did the whole job in one function: sample the model by
perturbing each variable, build the CoinMP matrix from those
coefficients, solve, and read the result back. Move the matrix
build and solve into a standalone helper, coinmpSolveLinearModel,
that takes the sampled coefficients plus the variable bounds and
column types and returns the solution and status.
The helper treats the first entry of each cell's coefficient vector
as the value of an affine model at the origin and the rest as the
per variable slopes, which is what the existing sampling already
produces. That keeps the same convention while letting a future
caller supply coefficients sampled around a different point and its
own bounds, which is what a sequential linear programming loop
needs.
No behaviour change. CoinMPSolver still samples and sets up bounds
and column types exactly as before, then calls the helper. The
CoinMP solver unit test passes unchanged.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I6d373a48caa9d67a932a599068368bae978f1f22
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4648
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 197f790a93880f56dd53db43e6bbb61c22ccfdc2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208337
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Somewhat surprisingly, it is very easy for Calc to report a selection
when the selection has actually been negated.
And sadly I didn't even see any examples in the code that checked.
ScViewFunc::SearchAndReplace early on calls
DoneBlockMode(true); // don't delete mark
which actually does delete the mark (if it has been negated).
So very quickly after HasSelection said that it did have a selection
this function cleared that status, so the rest of SearchAndReplace
operated on a no-selection state.
So ensure the correct state in srchdlg's TimeoutHdl_Impl
to prevent the user from requesting 'Current selection only'
when no selection is actually available.
Change-Id: Ifcafe251e68f036a25556cf5533d06337878d606
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208249
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
No Functional Change intended
This function is used very specifically for only UI stuff.
It is very different from any regular stuff.
So help to differentiate it by requiring the bool value.
To make sure I got all of them, I tested by requiring
a bogus OUString variable as well - make sure it compiled.
Change-Id: I4879427a806324d9fb9c033ef6b66ad24ba0bd54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208234
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Towards migrating off GDI font access.
This re-applies the change reverted in
bab072a4a1, after aligning the code with
hb_directwrite_face_create() to fix TTC handling and emmry mangement
issues.
Change-Id: I5954838bb41ab34cb89bab86e4dbd2ae1916c99f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208257
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Tested-by: Jenkins
By now, NotebookBar::m_pViewShell is always null and
NotebookBar::m_rDisposeLink is unset.
The method NotebookBar::SetDisposeCallback which would
have set both members was dropped in
commit 6f81bce807
Date: Wed Jun 3 12:34:28 2026 +0200
loplugin:unusedmethods
, so drop the now pointless members altogether.
Change-Id: Ib6392c22094601ebcc2349938e553a845fe0be06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208273
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
NotebookBar::m_bIsWelded is always false and
NotebookBar::m_bIsWelded is always an empty reference
by now, see also previous commit
Change-Id: Ic637b1e7026509b0736d877c88cf7bd6ca50b54c
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Jul 20 10:24:31 2026 +0200
vcl: Drop obsolete LibreOfficeKit path in NotebookBar ctor
. Therefore, drop them and related logic altogether.
Change-Id: I2a4c21728759207158f8f62049fe9edd85fac239
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208271
Tested-by: Jenkins
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is no longer used and e.g. the GetMainContainer
method that the comment refers to was dropped in the
meantime, see
commit 8754a75d98
Date: Tue Jun 2 14:47:57 2026 +0200
vcl: drop WeldedTabbedNotebookbar
"WeldedToolbar" no longer exists after
commit fd65cea59c
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Mon Jun 1 17:14:35 2026 +0200
drop notebookbar_online.ui
and
commit 6f81bce807
Date: Wed Jun 3 12:34:28 2026 +0200
loplugin:unusedmethods
(`git show --ignore-space-change` can help to see the
"actual change" more easily.)
Change-Id: Ic637b1e7026509b0736d877c88cf7bd6ca50b54c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208270
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
(e.g., libstdc++-devel-16.1.1-2.fc44.x86_64) after
f320d95d89ecc9bea81182795969f83b05ec903c "Avoid deprecated
std::filesystem::path::string",
> In file included from engine/codemaker/source/netmaker/netproduce.cxx:19:
> engine/codemaker/source/netmaker/csharpfile.hxx: In member function ‘std::string CSharpFile::getPath() const’:
> engine/codemaker/source/netmaker/csharpfile.hxx:31:27: error: ‘const class std::filesystem::__cxx11::path’ has no member named ‘display_string’
> 31 | return m_filePath.display_string();
> | ^~~~~~~~~~~~~~
etc.
Signed-off-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Change-Id: Ib51f9e0d0e1f902726f0d68a11fe28110388ef6a
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6554
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 63e9ab3b87cc5a793c8733e375dc86d99419a88d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208277
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The quick find (Ctrl-F) toolbar has a few hard-coded
keyboard shortcuts to find next or find previous.
However, those were undiscoverable to the user.
So, manually add one to the translatable label.
Hmm, this can be done automatically (the 'right' way)
via officecfg/registry/data/org/openoffice/Office/Accelerators.xcu.
However, these are not available to be set via the customize menu.
Nor do they work outside of the Find toolbar.
These are not user-customizable shortcuts.
They are hard-coded keys combinations in
svx/source/tbxctrls/tbunosearchcontrollers.cxx,
and thus are not language dependent.
An alternative would be to display Ctrl+G.
I chose F3 because it is a standard
for both Windows and Linux (KDE and Gnome).
[Gnome ALSO standardizes Ctrl+G, and that is what MacOS uses.
LO assigns Ctrl-G to .uno:RepeatSearch for macosx.]
make UITest_sw_findBar
Change-Id: If4b16d2e0c4abdd7656d58625a51ac7f40bdb242
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207972
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
This code is basically untouched since initial import.
For some reason, searching for patterns handled by Row
as if it was by Column - the opposite of text searching.
This patch fixes that.
Thanks to Julien Nabet who gave an initial try
and identified that looping again didn't work.
Change-Id: Ie6daa67e7d94bb1a5b8cd58158d20f1a383a7d77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208200
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This fixes a LO 3.5 regression
from commit 0783e78de2
Let's avoid modifying the selection data during search and replace
The problem was that only the first sheet's range was used,
and it was being applied to every sheet that had a match.
(Thus one reason why selection data was modified during S&R).
I would have LOVED to have some functions like ScRange(SCTAB)
or GetIntersectedRange(SCTAB). I almost created this one,
but the compile took so long, and it needed ScDocument passed to it
which made it look ugly - so I didn't bother in the end.
Change-Id: I6abc25fd4f7002d190632fe33963fdeb1af4b1ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208231
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
If the user has edited a cell, but has not yet pressed enter
and then they start/resume a search,
then the change being made might be applied to a different sheet.
Yeah - so stop editing before doing a search, eh?
I excluded SID_SEARCH_ITEM because that is called every time
the dialog starts/stops, any checkbox is ticked, etc.
So excluded for performance/extreme redundancy reasons.
I can easily imagine wanting to use search when building a formula,
so let us exclude that case as well. (see tdf#137899)
Change-Id: I61b22e668c7080c4f1786e1a720b1c8b4bafa68c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208223
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
If you search by Row or Column forwards,
you will loop back to the beginning.
If you search by Row backwards,
you will loop back to the end.
This patch adds looping when searching by Column backwards,
and it also works when 'All Sheets' is checked.
Change-Id: I23252671b47fe05953cfd386a46b1c065d512127
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208204
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Regression from 5707b5dce7
tdf#101083 speed up SVG rendering with pattern fill (2)
This is the same thing I did in
commit 3cbe3a0259
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Mon Jun 14 15:05:59 2021 +0200
tdf#101083 speed up SVG rendering with pattern fill
but cut and paste from the VclPixelProcessor2D to the CairoPixelProcessor2D code.
Which makes this SVG render in reasonable time when using the cairo backend.
We can probably do even better by cutting out the usage of VCL here, but this
is good enough for now.
+ apply the same as af2175bb87
crashtesting: divide by zero
since:
commit 7b807a6b79
Date: Fri Jun 21 12:28:30 2024 +0200
tdf#161086 bitmap location wrong with SVG with an embedded PNG
bodge it by using the requested width/height and not the possibly
zero on fail actual sizes
Change-Id: Ie0e0462e564a568f99d1c5b9c62f71049f71f9b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208275
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
The solver components reached every cell through the spreadsheet UNO API:
getSheets, then getByIndex for the sheet, then getCellByPosition, each with
a QueryInterface. That indirection is cheap once but expensive when it runs
for every variable on every evaluation.
Now that the solvers live in sc, recover the ScDocument from the document
through the UNO tunnel (ScModelObj) in setDocument and read and write cells
directly with ScDocument::SetValue and GetValue. Automatic recalculation is
turned on there as well, so writing the input cells and then reading the
recalculated objective and constraint cells behaves exactly as before. Both
the shared SolverComponent base (used by the CoinMP solver) and the
standalone SwarmSolver are converted.
The results are unchanged because the recalculation engine is the same. Only
the cost of getting values in and out of the document drops. The swarm solver
evaluates the objective for a whole population every generation, so this is
its hot path: on a 100-variable model its evaluation loop runs about four
times faster. CoinMP touches the cells only once, in a single pass that reads
off the linear coefficients, so it gains less, about 1.7 times faster on the
same model.
Library_solver now links sc and includes sc/inc. SwarmSolver keeps the UNO
cell lookup only for the uncommon case where a constraint's right-hand side
is given as a cell address.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I03ccec74cdc4d6cde30c86e048bf4314c3ca1397
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4047
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 929c17cf8e51a1510c32399de4a94ba946bb9919)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208281
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
to c1ec0774ee9e428b6cf5337e3bfbf3461bb0148d
- tdf#172674 add help for Better spacing/Less hyphen slider + interop.
Follow-up to core commit 5da16bdc79
"tdf#172674 offapi cui sw xmloff: add hyphenation slider feature".
Add also information about the requested minimum and maxinum
word spacing for MS-DOCX paragraph layout interoperability,
see core commit 5a48070f59
"tdf#126154 sw offapi xmloff cui: add min/max word spacing".
Change-Id: I66f3d5e1da69bcf7dc3d3b5cc85cc83400333814
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/208297
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Copy the value from the status bar.
According to the checkboxes selected in the submenu.
If “None” is selected, choosing “Copy Value...” saves
an empty string to the clipboard.
This effectively clears the clipboard.
Support for multiple national languages has been added.
Change-Id: I662e8be8feaeac5bf2e4d69f557a8fec2420ff47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207385
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
* Update translations from branch 'master'
to 165b4200a9471d813af4403952abdee5e06d17d3
- update translations for 26.8/master
and force-fix errors using pocheck
Change-Id: I1e57d23ac4e75387ef6b2480fcb18a23526b80dd
When the query has comments and the user clicks the
"Edit..." button, a dialogue with message
"The query contains SQL comments.
If you edit it in Design View, the comments will be lost.
Continue anyway or start editing in SQL View?"
pops up. There are 3 choices "SQL View", "Continue", "Cancel";
the first opens SQL view, the second goes to design view and
the last cancels the dialogue.
Change-Id: I1ea59ff24243ab8e3aeb09282f3c32dcb9b167af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208198
Tested-by: Jenkins
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
Adds a unit test which executes the macro in the utility document
AcceleratorKeyChecker.fodt. This should help make sure it doesn’t bit
rot if there are API changes in the core source code.
Change-Id: Id972dda31d0c8a09904e76dd6fd9760c9f2ad739
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208220
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
The macro in the document was relying on the document window directly
implementing the XAcessible interface. This is no longer the case so the
macro was hitting an error. This fix is based on the changes in the
commit below:
commit d1a25112bb
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jun 18 17:49:48 2025 +0200
java a11y tests: Don't rely on XWindow being XAccessible
Change-Id: Ie8cede2108f26e9d36cf1cf16e47f7ec5feab722
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208207
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
After previous commit
Change-Id: Iea0a2d64a552ff27ff5f8595f6d4379b6b224f94
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Jul 15 21:50:13 2026 +0200
vcl: Consolidate SystemWindow::GetWindowState callers
, only the variant directly returning the vcl::WindowData
is used outside of the class.
Cosolidate the two methods by merging them.
Change-Id: I0fb094a8ed583a9700ff64e34ebce86826320aa4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208172
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch/Simplify the 2 remaining callers of the variant with the
vcl::WindowData in/out param to use the one that takes the mask
and returns the vcl::WindowData.
Make the other variant private as it's by now only used
inside of the SystemWindow class itself.
Change-Id: Iea0a2d64a552ff27ff5f8595f6d4379b6b224f94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208171
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
So far, SalFrame::GetWindowState had a bool return value
and a vcl::WindowData* out param.
The comment said:
// if this returns false the structure is uninitialised
However, all implementations always return true.
All callers pass the pointer to a newly default-constructed
vcl::WindowData.
Instead, drop the (always true) bool return value and out param
and instead directly return the vcl::WindowData as the methods
return value.
For macOS, add a new vcl::WindowData member to the
RuninmainResult union, so this can be used as a return
value with OSX_SALDATA_RUNINMAIN_UNION in
AquaSalFrame::GetWindowState.
Change-Id: Icc55685cae9991a93fea43963273753d8aa2420f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208169
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of by pointer.
This makes clear it's non-null and allows to
drop some corresponding null checks.
Change-Id: I3e6c85c555ebcc0d949628e10fce891bc1c83fd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208162
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
macOS Tahoe had several problems that caused incorrect
drawing of tab items. To fix these tab item drawing
problems, commit 5b9881108b
would add the NSSegmentedControl as a subview of a window.
However, this caused extremely jittery window drawing
during live resizing if a window included any tab items.
Fortunately, as of macOS Tahoe 26.5.1, Apple had changed
tab item drawing so that the NSSegmentedControl now only
needs to be added as a subview when the window is not the
key window (i.e. the selected tab item is drawn disabled).
Since a window in live resizing is normally the key
window, Apple's changes eliminate the jittery window
drawing during live resizing.
Change-Id: I138528dea6661e49306c1085aee50f58b8ad4dfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208186
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
The patch fails for Windows so I put it specifically for Linux.
Done with the advice from Chatgpt (GPT-5.5)
With Python 3.14.6 from Debian testing (updated 2026-07-18) and no python in autogen.input
Traceback (most recent call last):
File "/home/julien/lo/libreoffice/workdir/UnpackedTarball/fontconfig/fc-const/./fc-const.py", line 181, in <module>
main()
~~~~^^
File "/home/julien/lo/libreoffice/workdir/UnpackedTarball/fontconfig/fc-const/./fc-const.py", line 158, in main
type=argparse.FileType('w'),
~~~~~~~~~~~~~~~~~^^^^^
File "/usr/lib/python3.14/argparse.py", line 1368, in __init__
warnings.warn(
~~~~~~~~~~~~~^
"FileType is deprecated. Simply open files after parsing arguments.",
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
category=PendingDeprecationWarning,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
stacklevel=2
^^^^^^^^^^^^
)
^
PendingDeprecationWarning: FileType is deprecated. Simply open files after parsing arguments.
Traceback (most recent call last):
File "/home/julien/lo/libreoffice/workdir/UnpackedTarball/fontconfig/fc-genericfamily/./fc-genericfamily.py", line 189, in <module>
sys.exit(main())
~~~~^^
File "/home/julien/lo/libreoffice/workdir/UnpackedTarball/fontconfig/fc-genericfamily/./fc-genericfamily.py", line 156, in main
type=argparse.FileType("w", encoding="utf-8"),
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.14/argparse.py", line 1368, in __init__
warnings.warn(
~~~~~~~~~~~~~^
"FileType is deprecated. Simply open files after parsing arguments.",
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
category=PendingDeprecationWarning,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
stacklevel=2
^^^^^^^^^^^^
)
^
Change-Id: I5a9e319562642c94b81076a33433a29ace32f400
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208245
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tomaž Vajngerl