Shows an icon in the statusbar if autocalc is off;
clicking the icon toggles autocalc on
Change-Id: I7fb3296281647583f6f761427d35dcd79282f06c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177418
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Version number was accidentally downgrade after re-saving with glade.
Change-Id: I266280884739dba65e97804d542f358a20e575f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177717
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
For some unkown reason (maybe due to the macOS two-level namespace?)
including the $(ICU_LIBS) link flags causes a crash on startup in
the macOS dynamic library loader on some versions of macOS running
on Intel machines. LibreOffice 24.8.3 and earlier did not have this
bug since libraptor2-lo was not linked against libicuuc. So, revert
back to the LibreOffice 24.8.3 macOS build behavior.
On macOS, libraptor2-lo still links successfully even without
libicuuc and the bundled JavaScript HelloWorld macro still runs. So
it appears that libraptor2-lo does not need any symbols in libicuuc
or, if it does, libicuuc has already been loaded by the time
libraptor2-lo is loaded.
Change-Id: I2e09ce57b5f7aea631a522f5d33f3a4b1ebfd419
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177594
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
windows build doesn't make use of system libraries, so we only need to
make autoconf/configure happy (allow it to use PKG_CHECK_MODULES macro)
but for that adding the m4/mac path is enough (there's nothing mac
specific, just the pkg-config macros have been added for mac initially)
Change-Id: Ia5db12833c26d89b7e0dbd7009562836885d8055
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177562
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
i.e. strawberry-perl-portable for the installsets and openssl
The only module that needs to be installed (and only when building
installation sets) is Font::TTF::Font - but only on the windows side,
not in the wsl-container.
in the wsl-as-helper case there are three different versions of perl
involved:
* one inside wsl, since autogen.sh is a perl script
* one provided by git-bash - used for the majority of the build
whenever a recipe uses perl
* and strawberry-perl-portable for building openssl (since that is
picky and needs one that handles the windows-paths a certain way)
and for building the installation sets (because of similar
assumptions in path mangling)
Change-Id: I8374749f21c7862f2e9e77d760077e836a6e9166
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177560
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Similarly to Filters, Column Fields, Row Fields, Data Fields boxes
the Available Fields box should be enabled to expand horizontally.
Change-Id: I36a6322ef528a18e2c37eb8f3397cf1aeeedc759
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177680
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Regression from commit 14c6cde779:
"tdf#49885 Updated CJK BreakIterator to use ICU"
Previously, languages requiring dictionary-based break iterators were
handled by instantiating a stock ICU break iterator as a special case.
tdf#49885 upgraded our custom rules to support passthrough for
dictionary-based breaking, so this special case is no longer necessary.
Change-Id: Iebb06de82eb511946e5b220e5dc414440838b03c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177713
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
This change fixes an infinite recursion crash while updating kashida
insertion positions. This crash could occur if a word is too long to fit
on a page and is broken onto another line, with the best-fit valid
kashida insertion position on the previous line, and the following line
also containing valid kashida insertion positions.
Change-Id: Ifc3320765f35ccdc49bbf179446bc03654e2596d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177709
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
MenuBar::GetWindow() and MenuBar::getMenuBarWindow
return a pointer to the same object, so there's no
need to use + check both for null.
Change-Id: I1b7065e4cd04a24e6215118a8dc71f147ed75132
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177699
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
pMenuBarWindow is non-null and was already dereferenced earlier
anyway.
Change-Id: Ieaeda4129d5c819fefa37dd3a186f76e035961b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177698
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This avoids the need to do a dynamic_cast and makes
clear that this method always gets called with either
a window of a proper type or nullptr.
Change-Id: I8ca4020476c806ad423379c7c7ee6fdc6ceccd3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177697
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use `pWindow` only to assign initial value to
`pMenuBarWindow`, then consistently use only the latter
instead of keeping both in sync and using interchangeably.
This also prepares for changing the `pWindow` param
from `vcl::Window*` to `MenuBarWindow*` in an upcoming
commit without upsetting clang plugins.
Change-Id: I07482e23c365ce39c4aa581fb42bf97ad03f6e1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177696
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Merge PopupMenu::PrepareRun into its only caller
which makes it a little easier to follow the logic
and track what's assigned to what local variable than
when using many out params.
Change-Id: Id967040a579e3f6532afa523215049bdb68f1cd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177694
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Application doesn't need access to any private members.
Change-Id: Ia69b64ecf8e380b0b8da7477e3a3c7d312629965
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177693
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
MenuFloatingWindow is the window used of PopupMenu,
while the window for MenuBar is MenuBarWindow.
MenuFloatingWindow only needs access to the menu
bar's MenuBarWindow, so make MenuBar::getMenuBarWindow
public and no longer let MenuFloatingWindow be a
friend of MenuBar, to make a little clearer who
is able to access whose private members,...
Change-Id: I7ee492e36d6e94884d1dba652d11f26cb8543a52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177692
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... and reset the view options that are toggled in
testHiddenParagraphFollowFrame and testHiddenParagraphFlys.
Backporting these tests to the libreoffice-24-8 branch broke 2 unrelated
tests because of the changed view settings:
Test name: (anonymous namespace)::testHiddenSectionPageDescs::TestBody
equality assertion failed
- Expected: 532
- Actual : 798
- In <>, attribute 'height' of '/root/page[2]/body/section[1]/infos/bounds' incorrect value.
xmltesttools.cxx:203:Assertion
Test name: (anonymous namespace)::testTable0HeightRows::TestBody
equality assertion failed
- Expected: 28
- Actual : 22
- In <>, XPath '/root/page[1]/body/tab/row' number of nodes is incorrect
Change-Id: Ie58242348fecabe163e54048f3896c6d427d2608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177691
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Pane shells (BottomImpressPane, LeftImpressPane etc.) do not implement any slot
handling, so make sure they are not activated on the top of the shellstack.
Another solution for this could have been getting ChildWindowPanes properly
dispose instead of Hide() at BasicPaneFactory::releaseResource, and adapting the
rest of the code which assumes these Panes are recycled.
This is since ConfigurationUpdater::UpdateCore attempts at releasing via
ConfigurationUpdater::CheckPureAnchors and
ConfigurationControllerResourceManager::DeactivateResources calls.
But in the end the ChildWindowPane is hidden on the DeactivateResource call
instead of being diposed, so the "PureAnchor"'s Shell stays at the shellstack.
Change-Id: I52788d350b66ae22875683f57d87326f4a9a77de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177686
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
Tested-by: Jenkins
field text ended in \ so next } was escaped
Change-Id: I2129f410a1d1c3d507a223c3576f02b78f7aac63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177681
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
... instead of manually casting the `m_pWindow`
member in another place.
While at it, also just call GetWindow()
in PopupMenu::ImplGetFloatingWindow, not explicitly
the base class Menu::ImplGetFloatingWindow. Both
are the same, as this is a non-virtual method
only implemented in the base class.
Change-Id: I12debc7c5bad8b21722fabb093cbc4a7a669dff1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177672
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
MenuFloatingWindow::pMenu is always a PopupMenu,
so use a VclPtr<PopupMenu> for it, instead of
a VclPtr<Menu> and casting in multiple places.
Change-Id: I004fc57063fc1cd50e5f14463367af3063a247b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177671
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Have a default SalMenu::GetSystemMenuData implementation
that does nothing instead of being purely virtual
and all subclasses except WinSalMenu::GetSystemMenuData
having to override it to do nothing.
Change-Id: Ia47af286f0fd3c1e3c6a00fff4512c9334fd6e9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177660
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
And drop the then no longer needed const_cast in
Menu::GetSystemMenuData.
Change-Id: Iac438850c5258e5fc23a4b3901f4601edf82e57c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177659
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This makes a bit more obvious that this is a class
member while reading code where it's involved, in
particular since local `pWindow` variables are
used in addition.
Change-Id: Ic68e856a0c3ddedbf510124937cf4bc21febf916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177658
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
There are two getters for that member:
Menu::ImplGetWindow and Menu::GetWindow.
Replace uses of the former with the latter
and drop Menu::ImplGetWindow.
Change-Id: Ieaefe43258172f6000c326503eeeefe1a05faabb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177657
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
this is temporary fix for caching the old values in
the text fields like page number. to be removed, we
need separate layers with awareness of fields
Change-Id: I74d8186441912ad110bff4bc6f46faff79a20cd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177664
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
A data array is a 1D array of 1D subarrays.
All arrays are presumed zero-based.
Usages:
- the content of a range of Calc cells returned
by the UNO XCellRange.getDataArray() or
XCellRange.getFormulaArray() methods
- the output of SF_Session.ExecuteCalcFunction()
- a tuple of (sub)tuples returned by a Python script
3 methods are added to the Array service:
1) ConvertFromDataArray(DataArray, [IsRange], [FillValue])
Convert a data array to a scalar, a vector or a 2D array.
On request, the individual items are reduced
to strings or doubles only.
2) ConvertToDataArray(Data, [IsRange], [Rows], [Columns)
Create a data array from a scalar, a 1D array or a 2D array.
The returned data array is zero-based and compatible
with the XCellRange.DataArray property when IsRange = True.
3) ConvertToRange(Data, [Direction])
Create a valid cells range content from a scalar,
a 1D array, a 2D array or a data array.
The individual items are always reduced to strings
or doubles. Including booleans or dates.
The returned scalar or array is a valid argument
of the SF_Session.ExecuteCalcFunction() method.
They replace the internal _ConvertFromDataArray()
and _ConvertToDataArray() that were present in
the Calc service, called by SetValue(),
SetFormula() etc. methods.
This change is Basic only and has no effect in Python.
The documentation about the Array service
should be completed with these new 3 methods.
Change-Id: Idc5b6417648e4574b0f9c7c6e2438ff7dfce1829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177620
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
seems to already exist in oldest version I have
Change-Id: I3f3652952476678c121cbe3f800b7adf7f7aa1a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177626
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
