strepsirrhini/office-gobmx
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

actualizacion-master-2024-12-06 #5

Merged
iapz merged 156 commits from actualizacion-master-2024-12-06 into master 2024-12-06 00:05:45 -06:00
Conversation 0 Commits 156 Files changed 477 +5636 -4732
iapz commented 2024-12-06 00:05:11 -06:00
Member
Copy link

Actualización para liberar release gobmx1.6

Actualización para liberar release gobmx1.6
iapz added 156 commits 2024-12-06 00:05:12 -06:00 
Change-Id: If29babb15d0e594e2746d6124218704e3f49728b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177670
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Change-Id: Ie010deb5cdf9da20f2ca60d79feabf1c0de93c57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177669
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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 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
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
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
Change-Id: I04cae4a880dcf5c34e35ade9983b56d8ff8ed496
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177661
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
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>
... 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>
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>
Change-Id: Iaca97dc3a0534847cbe96816a0827549a8f8d371
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177685
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Ic2781bbd25e794992a181b2f4807fc0ca08ef33b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177673
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
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
Change-Id: I85ef1d4e9391e211c9e5e7ac6e9de875e9f5f5af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Change-Id: I1357972c5ca8c6441533f15423134707efd36e33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177684
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
git show -w

Change-Id: I2963833726779d784bcdfa772e152e65dfde3af5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177674
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
... 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>
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
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>
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>
Commented out ever since

    commit 8ab086b6cc
    Author: Jens-Heiner Rechtien <hr@openoffice.org>
    Date:   Mon Sep 18 16:07:07 2000 +0000

        initial import

Change-Id: I147a6f6376e624bce2164d156e9360f99ac3b1d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177695
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
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>
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>
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>
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>
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>
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>
Change-Id: Iefac2a4e58248c9fcead2bcf97817488097fb20d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177711
Tested-by: Jenkins
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>
Change-Id: I82c470705add539fa425b084805a5da12eefa0ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176535
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Change-Id: I4b6bb9e3250a0f88f4fb99f3c9c8195c3c7a8f15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177714
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
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>
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>
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>
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
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>
Change-Id: I2d5f4e69b5cb9205743484c23443df2084da4fad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177721
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
We need to check rather the update button is visible instead of the
expanders.

Regression from commit: 13ac356a32
(tdf#164048 sw a11y: improve error/warning levels with...)

Change-Id: I63fb5906ad2f7bb13bc5822c284861a419897c4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177723
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Change-Id: I21345049d8137e43cc3e50b0b1bcc8d41a123458
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177582
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
This is needed for online, so the sidebar fills all the available
transitions.

Change-Id: Id3af1ed0272305fe7f1ab2d5dddd967276bbbb3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177727
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
a problem since:

commit 53d2a03904
CommitDate: Tue Jan 14 13:45:44 2020 +0100

    weld PageSizePopup

Change-Id: I5e55d1972a205b7bf1ec6f6bdfd2d8cd22e13eca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177728
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I907e282c9e7b75abca9a4c91ba12a2c57fc45f40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177733
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Change-Id: I49477c20849dd99118d5935c0f1576429648bfca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177734
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I0b0113d5e3a1652280e0d84c1beba7c572ded191
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177736
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
* Update translations from branch 'master'
  to 93f61b8759efdb510d3e24eac33e10c8231aedf8
  - Updated Slovenian translation
    
    Change-Id: I0f24e5a42d5d8650fec3dc21d199882691bbdbba
...new with GCC 15 trunk -std=c++26 since
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cc67d95dc100706ea665e8cce581d59466aba62e>
"c++: Implement C++26 P3176R1 - The Oxford variadic comma",

> In file included from workdir/UnpackedTarball/boost/boost/rational.hpp:82,
>                  from source/external/boost/include/boost/rational.hpp:30,
>                  from source/tools/source/generic/fract.cxx:32:
> workdir/UnpackedTarball/boost/boost/integer/common_factor_rt.hpp:66:56: error: omission of ‘,’ before varargs ‘...’ is deprecated in C++26 [-Werror=deprecated-variadic-comma-omission]
>    66 |          inline constexpr void constexpr_swap(T&a, U& b...) BOOST_GCD_NOEXCEPT(T)
>       |                                                        ^~~
>       |                                                        ,

and

> In file included from workdir/UnpackedTarball/boost/boost/move/unique_ptr.hpp:24,
>                  from workdir/UnpackedTarball/boost/boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:18,
>                  from workdir/UnpackedTarball/boost/boost/spirit/home/classic/core/non_terminal/grammar.hpp:21,
>                  from workdir/UnpackedTarball/boost/boost/spirit/home/classic/core.hpp:42,
>                  from workdir/UnpackedTarball/boost/boost/spirit/home/classic.hpp:24,
>                  from workdir/UnpackedTarball/boost/boost/spirit/include/classic.hpp:11,
>                  from source/external/boost/include/boost/spirit/include/classic.hpp:30,
>                  from sdext/source/pdfimport/pdfparse/pdfparse.cxx:23:
> workdir/UnpackedTarball/boost/boost/move/detail/unique_ptr_meta_utils.hpp:500:39: error: omission of ‘,’ before varargs ‘...’ is deprecated in C++26 [-Werror=deprecated-variadic-comma-omission]
>   500 | struct is_unary_function_impl<R (*)(T0...)>
>       |                                       ^~~
>       |                                       ,

Change-Id: I56856e274a7c577c53d96343992bb79d4c3d602e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177730
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
This reverts commit 598e93b1b11f4cdff96f6117c2a7d35f3698fd23.

Change-Id: Ifdbc8920f232d388eac2a07cd6e2e2dece204a7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177283
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177334
Tested-by: Jenkins
This reverts commit 8115c82f1f7f2621e2d99c93e1a3b2196279602a.

Change-Id: Ie3f389561ee8f734ac76b3dec352382281f91c30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177284
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177335
Tested-by: Pranam Lashkari <lpranam@collabora.com>
...in conditional format manager"

This reverts commit 399253ca8ca391504ff1f6a3709fb41d438ce2d6.

Change-Id: I3c0a79ee0a34364d0a51ab4736810f35efe4bfdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177285
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177336
Tested-by: Jenkins
This reverts commit 2a6dc9dfd84b278352608f475a600e866846af2e.

Change-Id: I061f8ebfbf0115dd55d357c325a3905c5a774a57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177286
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177337
Tested-by: Jenkins
This reverts commit 2661be5f8fb28ada80b4f5336d59f54b520bf614.

Change-Id: Ie3482641cbbb34baa866a679c782221d2d513df1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177287
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177338
Tested-by: Jenkins
...from condition format manager"

This reverts commit 8374dd472cb4a2e2edab969a73ca88ffeaadbcd8.

Change-Id: I532c17596adccfa5c88baaf2df897f3ffbee0fe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177288
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177339
Tested-by: Pranam Lashkari <lpranam@collabora.com>
This reverts commit 9928f1fa147d4ff838cbf6fcfe0d976ecef97cef.

Change-Id: Ieb7dfdeccaffed4ad81ff9b5b0eb3b3b49fd8d05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177289
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177340
Tested-by: Pranam Lashkari <lpranam@collabora.com>
This reverts commit 58c3f70c514ef4ce0de5419ab7daa3bebfb96f37.

Change-Id: I500a96508684547c158cdd1814540a4b24f667d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177290
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177341
Tested-by: Jenkins
When there are multiple competing configuration settings for the same
configuration layer (e.g., in xcu files of two different extensions from the
same extension layer), then the setting that is read last always won, even if
any of the settings read earlier is marked as finalized.  (The reason for
originally doing it that way was that it kept the code logic somewhat simple.)

However, esp. for a scenario of multiple extensions in one extension layer
(bundled, shared, or user), it can be unexpected by a user that a non-finalized
setting (that comes from the extension that happens to be read last) can win
over a finalized one.

Therefore, change the logic accordingly.  Now, if any of the competing settings
are finalized, the first finalized one that is read wins.

Change-Id: I22aeade543a5b26d95d49cfcb561f974cd7a5081
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177737
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Change-Id: I7066a328fa54c062d1a12582d4f270e70f466c32
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177702
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
Add new warning for empty paragraph between numbering paragraphs.

Change-Id: Ib85b376da77a72a87ab05a3e8271be43e223f129
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177493
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
jom (https://wiki.qt.io/Jom) is a parallel version of nmake that
especially helps with building openssl since everything is compiled
individually/the compiler cannot use parallelism either.
Also in a LibreOffice build there's not much else that can be done in
parallel/other stuff requires openssl to be built to continue.

Change-Id: Ib16b0f947991a1d3255aeae7dc5d9bdee0b157a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177743
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
* Update translations from branch 'master'
  to 9a24d35bd2100d7686503528bfce2cb2d6d18ca4
  - update translations for master/25.2
    
    and force-fix errors using pocheck
    
    Change-Id: I8cd66ba0ada8029d2c300d43b6c37ff7da3c3584
... even if there is a character format hint there - in this case, a
RES_TXTATR_AUTOFMT attribute will not be converted to the SwTextNode's
item set.

Also add a test that uses the XDocumentInsertable interface to insert
the HTML, which is closer to the real use case.

(follow-up to commit f45d2fa85b)

Change-Id: Idbf7efceabca8d43d3e32d0b29fb37a9322c184c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177740
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Change-Id: I7bbcc08786843d6d289b3170248ce2696e57f3b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177602
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
Don't apply inline heading 1) in a text frame
2) or if the selected text is over 120 characters.

1) It would be enough to limit this for inline heading
frames, but the recent FN_INSERT_FRAME – which is used
for creating the Inline Heading frame, cannot handle the
insertion inside a frame: the new frame is anchored outside
of the frame, not inside the actual paragraph, resulting
bad layout.

2) Increase also the limit of applying the inline heading
to 120 characters (very upper limit for a long line) from 75.

Follow-up to commit 7a35f3dc74
"tdf#48459 sw inline heading: apply it on the selected words",

Change-Id: I05de4be3a08926fdabad2e601d4bbe57ae25f7c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177739
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
* Update helpcontent2 from branch 'master'
  to ac15fc2c15fa9e188f0acf1749ca63c2ac228530
  - add missing screenshots & files for Tagalog help
    
    Change-Id: I078f85931d21441929737105e694e0936fd1531f
    Reviewed-on: https://gerrit.libreoffice.org/c/help/+/177748
    Tested-by: Jenkins
    Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
* Update helpcontent2 from branch 'master'
  to 0321da3f2b7fca3f7bda1655d64206f28231818e
  - Reapply "enable help for Tagalog (tl)"
    
    This reverts commit dc50ebde81a0e9266806878b69de81da422ec39c.
    
    Change-Id: I0795bff471896fba0972f6e8e44cc81b97e66ccd
    Reviewed-on: https://gerrit.libreoffice.org/c/help/+/177749
    Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
    Tested-by: Jenkins
Downloaded from https://www.python.org/ftp/python/3.10.16/Python-3.10.16.tar.xz

Change-Id: I677c1dec6ac1d06596d7ff88269b6cac70d848c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177757
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
This reverts commit 60df7e1052.

Reason for revert:
Michael Stahl: "the PVS warning is wrong, checking bChgFillData is already enough"

Change-Id: I7d963e2b2ebbb30195af05b70ad36ab8d78e7c25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177760
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Change-Id: I9cc0413f6c0af3be6ef83f4dbcf8dcf73b992f92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177643
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
No need for a map to remember the implementation - we can just
dynamic_cast to the actual implementation.

Change-Id: If590316023be7f749d270c04b7ad3dc5fa1993b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177644
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Change-Id: I3d7fdcfe2c4ec0f716425c349b0bf621809fd249
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177741
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
- also removes unused PreviewValueSet

Change-Id: I5e7dacb4f472de526a61366295bc91edca12e9ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177642
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Change Menu::ClosePopup param from Menu* to
the child class PopupMenu*, as this is always
a PopupMenu. This also removes the need to
cast to PopupMenu in the PopupMenu::ClosePopup
override.

Change-Id: I129e6ebc7c801c1ca93514f26f79b76f970957a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177745
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use existing PopupMenu::ImplGetFloatingWindow
instead of casting manually.

Change-Id: I9449130e077fc997d724d5fadc854a278ba16cce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177746
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move logic to the only caller that passed something else than
the default nullptr.

Change-Id: I293f2ca7ccd22f8f0f57a7fd91a6b4dfaa6a8846
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177747
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Change-Id: I05ff47fe51cccce6a78745027ae8c2679783bd8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177766
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This fix offers two options to preserve the overflowed text:
1: if the "Original size" option is selected for printing,
   the overflowed text will be displayed on a new page.
2: if the "Fit to Printable Area" option is selected for printing,
   notes will be scaled to fit within the available printable space.

The "Multiple sheets of paper" and "Tile sheet of paper" options are disabled for notes because these options are intended for slide printing and do not make much sense for printing notes.

The orientation for the notes print page has also been fixed.

Change-Id: I99e56cf9aed5c32764797469a8ea7f3b25053882
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177511
Reviewed-by: Nagy Tibor <tibor.nagy.extern@allotropia.de>
Tested-by: Jenkins
The ExecuteCalcFunction() method is a wrapper
of the
   com.sun.star.sheet.FunctionAccess::callFunction()
method.

This method accepts a broad variety of arguments
- scalars: numeric and strings only
- data arrays (= arrays os arrays)
- 2D arrays (1D arrays give errors)
- com.sun.star.table.XCellRange objects
depending on the called function and its
execution or not as an "array function".

The actual commit makes that the arguments passed to
   session.ExecuteCalcFunction()
are checked as formally correct: scalars are filtered
as numeric or strings, dates and booleans are converted,
arrays are reshaped to 2D where necessary.

The actual change facilitates, as an example,
the use of complex array functions like XLOOKUP,
a powerful search engine on large data sets.

The implemented functionalities are valid in Basic
and Python.

The help documentation might be completed with
additional examples.

Change-Id: I6bba1e21828ef09c5c6f0463cbcfa1f5df695073
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177744
Tested-by: Jenkins
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Change-Id: Iac4a64af74c92cbd76335faa62e51fa80ef21789
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177718
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Change-Id: I4d9f76cc5cb767054e138819d2b8dd9032188c6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177770
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
A static variable has been added so that, when merging cells in Calc
where multiple cells have content in them, it will remember which of the three
merge options was last used in a given session and automatically select that
option the next time the merge cells dialog pops up. The default for the first
merge in a session remains the option to keep the content of hidden cells.

Change-Id: I35f6c01ffe9dff2756e3b9f5d530725e5d939db8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177455
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
gtk_icon_view_convert_widget_to_bin_window_coords was
dropped in gtk commit [1]

    commit 8dc5e13e8c66cd260edff17dbaa10eedcc95ae1b
    Author: Timm Bäder <mail@baedert.org>
    Date:   Tue Jun 27 11:11:57 2017 +0200

        iconview: Remove bin_window

, so make the code using it conditional for gtk3.

This at least unbreaks the build for now after

    commit a36a58933a
    Date:   Mon Nov 25 17:07:59 2024 +0530

        sd: convert sidebar masterpage panels from drawingview to iconview

It's possible gtk4 needs to do something else instead,
but that can still be added later.
See discussion newly started at [2] which might
give some insights.

[1] 8dc5e13e8c
[2] https://gerrit.libreoffice.org/c/core/+/177642/comment/4edf0ddd_f71cb30b/

Change-Id: I3bd42614addd03d483c7b41daa2b3a4677b9318e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177769
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Change-Id: Iffb4b464ff124ffce19548a756d878130c10921a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177772
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
this shouldn't happen unless the rdb is broken

Change-Id: I3e861d25a8c10243f03446ec8a7b44457186585a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177774
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Change-Id: I8d9cf983ca8c96d1619aceff9113732814d09f09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177773
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
we are already at the column data level, no need to call via ScDocument

Change-Id: Ib8b0bc0f1fd9782229dc6c5240f87c086bdc970c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177777
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
which avoids a lot of lookup cost

Change-Id: I9b030f3f8402f05a5c7b03c0147ff3ffc91d1cdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177778
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which reduces save time to around 30s for me

Change-Id: I6889312d25bd8f297f1c54f683496ef00e114d51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177779
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... in D2DWriteTextOutRenderer.

Commit 785a56b6be (D2DWriteTextOutRenderer:
use grayscale AA for file output, 2024-11-27) has disabled it only when
the export settings explicitly specified a concrete AA setting. In case
when the settings didn't specify explicitly, if AA should be used or not,
then system settings were used, which in case of D2DWriteTextOutRenderer
would still enable ClearType (subpixel AA).

This stores additional flag in StyleSettings, similar to what was done
in commit e6538f5bdd (tdf#118966 vcl: add
a flag to determine if AA of fonts is used from the system, 2018-07-28),
that tells the renderer to prevent subpixel AA, even if use of AA itself
is defined by system settings. This flag is currently only considered by
D2DWriteTextOutRenderer.

Change-Id: Ibd1879d3c222276eee00c37a442881d6d47c831f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177780
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I7a4c19d9344dba9c09861fe78b864a8651c3286f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177771
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
we need to be aware of hidden slides to make correct
decision when doing "start from current slide" based
on the slide number

Change-Id: Ib4944c699fa2589026e4d8ae57766c83e0439d49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177775
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* Update translations from branch 'master'
  to 6eca395810730a005bd24fcafa92eba4860350b9
  - update translations for master/25.2.0 Beta1
    
    and force-fix errors using pocheck
    
    Change-Id: I291ff1a663a6689b727528a376ac200d4041281d
Change-Id: I8b5394fb5119e124240a567e99497337ff897686
Change-Id: Iac334c822ab0699b5cc5122e5f2b1a2b9662f58e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177784
Reviewed-by: Skyler Grey <skyler.grey@collabora.com>
Tested-by: Jenkins
2nd arg to copy is len, not index. Probably a problem since:

commit 12a7a3d57d
CommitDate: Thu Sep 3 15:33:36 2020 +0200

    Fix crashtest fdo77855.odt

in forum-es-2526.odt the input has:

fo:border-=".009cm solid #595959"

where 'fo:border-' is an unknown attr and "fo" ends up truncated to "f".
On export and reimport the 'f' is further truncated to '' and we assert
on this oddness.

Change-Id: Ie85d81947504bf15b9caefb92477c7f977eb5cb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177788
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
to make it easier to read

Change-Id: Ifaece90d4fb18be3caae9fd4afbbbdf64ff9d18a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177800
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
The call sites are actually passing in transparency, in fact to be
consistent with current conventions we are actually dealing with alpha
values. So we need to take the transparent values at the call sites and
convert to alpha values by just subtracting 255. Hence fixing the FIXME
comment.

Change-Id: Ibc55ea77f469ec8afcab0cc26d2b8cdf25ea8a72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173858
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
To make it easier to see the modifications I want to do to improve
performance here.

Change-Id: Icbb663b39905ce0fe82544bac7afd21314d4c7c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177801
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Change-Id: I445ec8a08c6622c681e459efc2dd2afbf74dd78e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177794
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Pass arguments right away in ctor rather than
having a ctor that takes no arguments and then
having to call VCLXFont::Init with the arguments
right after calling the ctor.

Change-Id: I651e27154499f61638409377438f9589bc7412a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177795
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This method from the unpublished XAccessibleExtendedComponent
interface is not used by any of the a11y platform bridges, and
I don't know of any platform a11y API that would need it.

In order to report character/font attributes, there is the
XAccessibleText interface and its
XAccessiText::getCharacterAttributes method instead, which
actually gets used by the platform a11y bridges.

Therefore, drop this method to simplify code, and also decouple
the accessibility module a bit further from the toolkit
module without having to reorganize code further.
(VCLXFont from the toolkit module currently gets used in
various implementations.)

Change-Id: I06ea3cc5998a13927b3f869877b28f03ac07c89b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177809
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This is in preparation of moving more from
the accessibility module to vcl.

Currently, the a11y implementations for vcl widgets
are implemented in the accessibility module (in
directory of the same name), which in turn depends
on the toolkit module.
To break the dependency cycle (vcl needs accessibility
to create a11y objects for its widgets), there's a UNO
service.

At least some a11y classes don't really need toolkit,
however, so the plan is to decouple this and move those
from the accessibility module into vcl in upcoming
commits.

Change-Id: I6aeee104f271c804c85727002822b89a9263628f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177810
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... so these constants can be reused in vcl.

See commit message of

    Change-Id: I6aeee104f271c804c85727002822b89a9263628f
    Author: Michael Weghorn <m.weghorn@posteo.de>
    Date:   Wed Dec 4 11:45:44 2024 +0100

        a11y: Move CharacterAttributeshelper from accessibility to vcl

for motivation.

Change-Id: I1552c0a0111c81643ab9bb6f202c8a31662251d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177811
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move helpers to convert between the Rectangle, Point and Size
classes in vcl and in css::awt from VCLUnoHelper (in the toolkit module)
to vcl::unohelper (in the vcl module), for reuse in vcl in upcoming
commits.

Change-Id: I7b11c8a6b8c843a01ce25b1e4c0fb1869ad1e6ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177816
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Other than most of the a11y implementations for vcl
classes, VCLXAccessiblePopupMenu etc. do not
make use of any VCLXWindow (i.e. UNO/toolkit wrapper of a
vcl::Window) and thus do not depend on the toolkit
module, which the accessibility module depends on.

Therefore, there's also no need to use the accessible
factory to create them (which is needed when toolkit
classes are involved to avoid a dependency cycle).

Move those classes from the accessibility module to
vcl and add a new method Menu::CreateAccessible and
move the logic from AccessibleFactory::createAccessible
there. Drop the now unnecessary factory methods
previously used for those classes.

No change in behavior intended (yet), but this
also simplifies the code involved for the
tdf#164093 scenario.

Change-Id: Ie3f6f1a02bf6662206d31383473cdc868e1f9164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177812
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Use the vcl::Window for the null check instead of the
corresponding VCLXWindow. There's no need to
use a toolkit class here, in particular since the
vcl::Window is used later anyway.

Change-Id: Ia2c80f9634eadf33601af8c9ea1f628e7ea3e96b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177813
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of using the toolkit/UNO wrapper
SVTXNumericField.

Change-Id: I86e274a06f210e2076e287087a1d4b979abe7c35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177814
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... instead of using the toolkit/UNO wrapper class
VCLXCheckBox.

Change-Id: I271535f3e2e46202e2ca3d2e3f9a1d05ac380c41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177815
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Change-Id: Ie50fd8bb2bbb26962ead459fe8014828c99fd755
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177789
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* external/gpgmepp/gettid.patch issue fixed upstream

Downloaded from https://gnupg.org/ftp/gcrypt/gpgme/gpgme-1.24.1.tar.bz2

Change-Id: Id2d984f5e68b8681bf5e635a1afe5d90605711ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177821
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Clip stroke paths coming from the PDF import.
Similar to my previous patches for fills.

(It's possible we might have to do something clever with cropping
of arrows/etc but not sure yet)

Change-Id: I9e46deac4a722e3ac510f0cc4bdb6b38b67c579e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176952
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Not relying on rData.pCellTransfer anymore since it is always null
when rEvt.mbLeaving is true.

Change-Id: I4755e8f9b62efacd2eb4d515e1993578beadef09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175970
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Change-Id: I54fbdebbd5287f1e832ed662986b8b3fa45fbe45
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177583
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Change-Id: Ib09f054eca56d55ba6b91c8e2377f373fc615430
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177808
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
attribute of drawing objects (placeholders)

Export spAutoFit attribute correctly to ooxml.

Change-Id: I57e5b21bd6c407bdb5d1b36b3c3674249fbd2f59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177798
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Used e.g. by the "Find and Replace" dialog (Ctrl+H).

Change-Id: Ie181eea1600616ddb6a8044864df221ac4bb108d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177826
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
These are needed e.g. for the "Find and Replace" dialog.
Use the QWidget::geometry property [1] for now.
An alternative to consider might be QWidget::frameGeometry [2].

At least on Wayland, screen positions are not available
anyway, however.

[1] https://doc.qt.io/qt-6/qwidget.html#geometry-prop
[2] https://doc.qt.io/qt-6/qwidget.html#frameGeometry-prop

Change-Id: I2449d8be688c17a4abb58ba424c966dde0e30e26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177827
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Map to/from what looks like the corresponding QWidget
equivalents.
No explicit testing done.

Change-Id: I47152c8789223372c49ea60f774d0a04a64db2b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177828
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reuse the logic previously implemented in
QtInstanceEntry::set_message_type by moving it to a
static helper method that takes a QLineEdit* param,
and for QtInstanceComboBox::set_entry_message_type,
pass the combo box's line edit.

Change-Id: I8e81c9473da294d2a8c863ed143d735c30ade2a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177829
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Not doing so would e.g. trigger an assert when
toggling the "Match case" checkbox in the "Find and Replace"
dialog in a WIP branch where support for that dialog with
native widgets is declared.

Change-Id: I5dc95e81e81bceaf258ecba6e55dfa280dfdd572
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177830
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
As the comment for weld::ComboBox::connect_changed
(in vcl/include/weld.hxx) says:

    /* m_aChangeHdl is called when the active item is changed. The can be due
       to the user selecting a different item from the list or while typing
       into the entry of a combo box with an entry.

       Use changed_by_direct_pick() to discover whether an item was actually explicitly
       selected, e.g. from the menu.
     */
    void connect_changed(const Link<ComboBox&, void>& rLink) { m_aChangeHdl = rLink; }

QComboBox::currentIndexChanged is not emitted while
typing in an editable combobox, so connect to the
QComboBox::editTextChanged signal in addition.

Also, hold the SolarMutex when calling the signal handler.

QtInstanceComboBox::changed_by_direct_pick isn't implemented
yet, but would trigger an assert when called, so this doesn't
go unnoticed at least.

Witht this commit in change, typing in the "Find"
combobox in the "Find and Replace" dialog in a WIP
branch declaring support for that dialog now results
in the buttons getting enabled or disabled as expected
(disabled when text is empty, enabled when non-empty).

Change-Id: I9b89b3a3c8b5ed7ebdeda7b486bdbf2f7e54fd86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177831
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This e.g. gets called when pressing the "Find Next" button
in the "Find and Replace" dialog.

Change-Id: I30e33d52d19b0afe44564486bfa79e3b500ae856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177832
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Also add Q_OBJECT macros for all subclasses
that didn't have them and run moc for them, too.

Change-Id: Ia42ee7d02b68d54df308d33c88bf286468bfa68f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177833
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Similar to what already exists in most subclasses,
add signal_<event_name> methods to call the handlers
and use these in the subclasses instead of calling
the handlers directly.

Change-Id: I6b79ddd859b360e947d97ada57f1573a276d6177
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177834
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In QtInstanceWidget, connect to the QApplication::focusChanged
signal [1] and when either the old or the new focus widget
is the one belonging to this QtInstanceWidget, notify
about the lost/gained focus.

With this in place, SvxSearchDialog::FocusHdl_Impl
now gets called in a WIP branch where support for the
"Find and Replace" dialog is declared when moving
focus into one of the comboboxes in that dialog.

[1] https://doc.qt.io/qt-6/qapplication.html#focusChanged

Change-Id: I15190cf9b0d2e72d78a57f58da7ff2ebd1e7a6d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177835
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Previously, Writer was not correctly terminating layout contexts at the
starts of small caps spans. This could cause incorrect character
placement in certain cases.

Regression since:

Commit 30d376fb7d
    "tdf#61444 Correct Writer text layout across formatting changes"

and

Commit ab0a4543ca
    "tdf#124116 Correct Writer text shaping across formatting changes"

Change-Id: I863b9b66356eb0a9efb5bbdc75e80b43d56aaaf0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177839
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
The option also affects hyphen and the label should reflect this

Change-Id: I5e092f8c5d67c1c039de709d024c89481b40a82d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177841
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
no need to copy things to a std::deque, it is quite straightforward to
just iterate over the SwNodes structure.

Shaves off about 30% of the time spent processing post-load.

Change-Id: I852079c18738299be04cec52b82e0f6949f2d81c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177837
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
A crash was reported in HasOnlyOneListener, with the following call stack:

 ntdll.dll!KiUserExceptionDispatch()
 swlo.dll!SwModify::HasOnlyOneListener() Line 204
 swlo.dll!SwFormatField::~SwFormatField() Line 142
 swlo.dll!SwHistorySetTextField::`scalar deleting destructor'(unsigned int)
 swlo.dll!std::default_delete<SwHistoryHint>::operator()(SwHistoryHint *) Line 3090
 swlo.dll!std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>::{dtor}() Line 3198
 swlo.dll!std::destroy_at(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * const) Line 311
 swlo.dll!std::_Default_allocator_traits<std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::destroy(std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>> &) Line 688
 swlo.dll!std::_Destroy_range(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * _First, std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * const) Line 905
 swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::_Destroy(std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> * _Last, std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>> *) Line 1667
 swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::_Tidy() Line 1751
 swlo.dll!std::vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>::~vector<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>,std::allocator<std::unique_ptr<SwHistoryHint,std::default_delete<SwHistoryHint>>>>() Line 699
 swlo.dll!SwUndoSaveContent::~SwUndoSaveContent() Line 740
 swlo.dll!SwUndoDelete::~SwUndoDelete() Line 633
 swlo.dll!SwUndoDelete::`scalar deleting destructor'(unsigned int)
 svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
 svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
 svllo.dll!std::destroy_at(MarkedUndoAction * const) Line 311
 svllo.dll!std::_Default_allocator_traits<std::allocator<MarkedUndoAction>>::destroy(std::allocator<MarkedUndoAction> &) Line 688
 svllo.dll!std::_Destroy_range(MarkedUndoAction * _First, MarkedUndoAction * const) Line 905
 svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Destroy(MarkedUndoAction * _Last, MarkedUndoAction *) Line 1667
 svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Tidy() Line 1751
 svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::~vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>() Line 699
 svllo.dll!SfxUndoArray::{dtor}() Line 1389
 svllo.dll!SfxListUndoAction::~SfxListUndoAction() Line 1318
 svllo.dll!SfxListUndoAction::`vector deleting destructor'(unsigned int)
 svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
 svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
 svllo.dll!std::destroy_at(MarkedUndoAction * const) Line 311
 svllo.dll!std::_Default_allocator_traits<std::allocator<MarkedUndoAction>>::destroy(std::allocator<MarkedUndoAction> &) Line 688
 svllo.dll!std::_Destroy_range(MarkedUndoAction * _First, MarkedUndoAction * const) Line 905
 svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Destroy(MarkedUndoAction * _Last, MarkedUndoAction *) Line 1667
 svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::_Tidy() Line 1751
 svllo.dll!std::vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>::~vector<MarkedUndoAction,std::allocator<MarkedUndoAction>>() Line 699
 svllo.dll!SfxUndoArray::{dtor}() Line 1389
 svllo.dll!SfxListUndoAction::~SfxListUndoAction() Line 1318
 svllo.dll!SfxListUndoAction::`vector deleting destructor'(unsigned int)
 svllo.dll!std::default_delete<SfxUndoAction>::operator()(SfxUndoAction *) Line 3090
 svllo.dll!std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>::{dtor}() Line 3198
 svllo.dll!std::destroy_at(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * const) Line 311
 svllo.dll!std::_Default_allocator_traits<std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::destroy(std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>> &) Line 688
 svllo.dll!std::_Destroy_range(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * _First, std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * const) Line 905
 svllo.dll!std::vector<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>,std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::_Destroy(std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> * _Last, std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>> *) Line 1667
 svllo.dll!std::vector<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>,std::allocator<std::unique_ptr<SfxUndoAction,std::default_delete<SfxUndoAction>>>>::clear() Line 1442
 svllo.dll!svl::undo::impl::UndoManagerGuard::~UndoManagerGuard() Line 325
 svllo.dll!SfxUndoManager::ImplClearRedo_NoLock(const bool i_currentLevel) Line 468
 swlo.dll!sw::DocumentContentOperationsManager::InsertPoolItem(const SwPaM & rRg, const SfxPoolItem & rHt, const SetAttrMode nFlags, const SwRootFrame * pLayout, SwTextAttr * * ppNewTextAttr) Line 3694
 swlo.dll!SwXTextField::attach(const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> & xTextRange) Line 1972
 swlo.dll!SwXText::insertTextContent(const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> & xRange, const com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextContent> & xContent, unsigned char bAbsorb) Line 606
 mscx_uno.dll!`anonymous namespace'::cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy * pThis, bridges::cpp_uno::shared::VtableSlot aVtableSlot, _typelib_TypeDescriptionReference * pReturnTypeRef, long nParams, _typelib_MethodParameter * pParams, void * pUnoReturn, void * * pUnoArgs, _uno_Any * * ppUnoExc) Line 214
 mscx_uno.dll!unoInterfaceProxyDispatch(_uno_Interface * pUnoI, const _typelib_TypeDescription * pMemberTD, void * pReturn, void * * pArgs, _uno_Any * * ppException) Line 430
 binaryurplo.dll!binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny * returnValue, std::vector<binaryurp::BinaryAny,std::allocator<binaryurp::BinaryAny>> * outArguments) Line 239
 binaryurplo.dll!binaryurp::IncomingRequest::execute() Line 79
 binaryurplo.dll!request(void * pThreadSpecificData) Line 84
 cppu3.dll!cppu_threadpool::JobQueue::enter(const void * nDisposeId, bool bReturnWhenNoJob) Line 101
 cppu3.dll!cppu_threadpool::ORequestThread::run() Line 169
 cppu3.dll!threadFunc(void * param) Line 190
 sal3.dll!oslWorkerWrapperFunction(void * pData) Line 67

I don't know why pType->Which() succeeded before the broadcast and reset,
and pType->HasOnlyOneListener() crashed; field destructors themselves do
not seem to destroy their types (except SwDBField, which is handled here
explicitly). My blind guess is, that a change could happen in broadcast.

Change-Id: I5c7f07da2e1283510bce3a3e3e80b6f8d849f38b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177854
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
but still has the same problem as the gtk3 iconview with reporting
positions when scrolled

a problem since:

commit a36a58933a
CommitDate: Wed Dec 4 07:40:30 2024 +0100

    sd: convert sidebar masterpage panels from drawingview to iconview

Change-Id: Ice549b40d88c5d2063e37ccb63490e3537736d39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177855
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I8d9daaf14829e20dfd16817dcb7b90c18fb78939
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177703
Tested-by: Jenkins
Reviewed-by: Simon Chenery <simon_chenery@yahoo.com>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Change-Id: Ia445fefad176685a8e4d3f78372b33e219c7832d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177704
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Change-Id: I0b9be4ea10c3837007158771fde46ad70e5c52a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177785
Reviewed-by: Jean-Pierre Ledure <jp@ledure.be>
Tested-by: Jenkins
which causes problems on export to docx. Sanitize at the original
import.

Change-Id: I3b5521dac6a2b6926db6362d33500b11f0a69098
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177869
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
It turns out the majority of getCommandValues() return values specify a
commandName and a commandValues key, which is helpful when we don't
track the request for this reply.

Fix .uno:Signature to do the same for consistency.

Change-Id: I46ffe5c36047ef2b59113d0221a1874ba28d335b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177857
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Make non-breaking space and hypen visible

Change-Id: Ibe088c752b9d8378bb167133df3c8fdeacf1f1eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177850
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Signed-off-by: Avramoniu Calin <clavramoniu@gmail.com>
Change-Id: Ib894b61edc15d4a89e7a83bb990a2819084879f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177397
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
follow up for f5ebf512ccd3d5ae3af5fe706b411a85fa19182d

now same actions are performed on all the dialogs

Change-Id: I6531a766327dda106770a2c513ebd492dea7c655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176933
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 2fba6df7242586870988b62909156538b42c2bc0)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177892
Tested-by: Jenkins
Telegram group.

Change-Id: Ib0ab77fafde0a7a5abc719a7eec9ef32615f15c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177853
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Change-Id: Ifc63db272484e9a7986e6113989f2f6274f40349
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177846
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This was using a weak reference when the comment
was added in

    commit 9b34eb7c85
    Author: Frank Schönheit <fs@openoffice.org>
    Date:   Thu Apr 25 10:24:33 2002 +0000

        #98750# be an XEventListener at the AccessibleContext

, but later changed to be a hard reference in

    commit 23d689d4e4
    Author: Thomas Benisch <tbe@openoffice.org>
    Date:   Thu Nov 7 16:19:24 2002 +0000

        #103674# change the reference to the accessible context from weak to hard

. Unfortunately that commit only references a StarDivision
internal ticket, so the exact reason remains unclear,
but at least update the comment.

Change-Id: Icdc9aec97647ae05ae7fb3f2bdc1be43c3a62619
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177848
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Change-Id: I791ec6d822573e18c981343d3ce8371acf0b3b38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177878
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Application::GetTopWindow also takes a tools::Long param,
so there's no reason to cast to sal_uInt16.

Change-Id: Ic592262bee8173329986ccb83298a26deb3586b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177879
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The method only gets called from AccessBridgeUpdateOldTopWindows
which always passes a non-null window.

Change-Id: I7d6d4effb75c722af6176257b8f296b5a77734cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177880
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Change-Id: I794e486b3e5e7d341a05cec20cc218dd2cd7e242
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177881
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
It's unclear to me why the list child's accessible should
be passed instead of the window's here.

In addition, AccessBridgeHandleExistingWindow is only relevant
when the AT brigde is started, i.e. for example when starting
a screen reader while LO has been running already. This makes
this look even less relevant and unclear to me why special handling
would be applied for that case, but not when a combobox popup
is shown when a11y has been active before already.

Change-Id: Ie7b16de36889e2432f6ac9455ab297ca16d3b26e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177882
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
In MenuFloatingWindow::dispose, unset the accessible
before calling the base class implementation, to prevent
the accessible from getting disposed there as well.
This is necessary because the MenuFloatingWindow
doesn't create (and therefore own) its accessible
object, but returns that from its menu in
MenuFloatingWindow::CreateAccessible. Therefore,
the PopupMenu as the owner is responsible for disposing the
accessible as well, not the MenuFloatingWindow.

This logic was already implemented in Menu::dispose,
but that doesn't help in cases where the MenuFloatingWindow
gets disposed independently.

In Menu::dispose, drop the extra logic
and just call `m_pWindow.disposeAndClear`
so that MenuFloatingWindow::dispose can
take care of everything that's needed.
(For the MenuBar case, MenuBar::dispose
calls MenuBar::ImplDestroy, which unsets
Menu::m_pWindow, so other than for PopupMenu,
this change to MenuBar::ImplDestroy method doesn't
make a difference for that class.)

Don't dispose the current Menu::m_pWindow in
PopupMenu::FinishRun, but instead in
PopupMenu::ImplExecute (if set) before assigning
a new one, to ensure that the old one gets disposed.
Drop the

    SAL_WARN_IF(GetWindow(), "vcl", "Win?!");

because that case is handled fine now. Without this
change in place, I saw that warning getting triggered
while debugging (potentially because PopupMenu::FinishRun
never got reached as the menu didn't show,  maybe due to
switching focus to the IDE when reaching a breakpoint
or different timing,...).

This commit by itself doesn't yet fix the crash
from tdf#164093 seen on Windows with NVDA running
because the menu's accessible still incorrectly gets
disposed by the MenuFloatingWindow's VCLXWindow
(toolkit window peer). That will be addressed
in a separate commit.

Change-Id: Ia2931bee23204395e8b3396927acf4fa1d0f077c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177883
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
No need to have `pAccessibleContext` as a raw
pointer, just use the `xContext`. And that one
has already been checked for being a non-empty
Reference above.

Change-Id: I15d7e70ddbc8b260e5e1bc0eb4e190c54d6a2ea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177884
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... instead of a pointer, to make clear
that this is always non-null.

Change-Id: Ic0f92e672b08494cf3bfaa9a956cb78170bc1ad5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177885
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... instead of a pointer, to make clear
that this is always non-null.

Change-Id: I4c8676913b2507f077d8a66973ab5f95e73cb497
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177886
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Window::GetSystemData should never throw an
exception, so there's no need for exception
handling here. Also, return early if the
system data is null.

Change-Id: I65794f10019d0c2fb5cc7150500b551c31cc2a08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177887
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
There's no need to have local raw pointer variables
in addition to the existing References.
Replace all uses of the former by using the latter
and drop duplicate checks.

Change-Id: I1339dabecbe8e1652e49df8ecd5ce2749b897f47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177888
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
By default, a vcl::Window's XAccessible is its
VCLXWindow (toolkit peer):

    css::uno::Reference< css::accessibility::XAccessible > Window::CreateAccessible()
    {
        css::uno::Reference< css::accessibility::XAccessible > xAcc( GetComponentInterface(), css::uno::UNO_QUERY );
        return xAcc;
    }

However, that's a virtual method and subclasses can
return a different XAccessible.
MenuFloatingWindow::CreateAccessible returns the
accessible of its menu.

However, winaccessibility's AccTopWindowListener
code was relying on the Window's XAccessible always
being its VCLXWindow.

The VLCXWindow is passed as a param in the
XTopWindowListener methods, and AccTopWindowListener
was querying it for the XAccessible interface, and
then calling XAccessible::getAccessibleContext in
order to retrieve the XAccessibleContext for the
window.

This is incorrect if the Window actually has another
XAccessible.

For the df#164093 scenario with NVDA running, opening and
closing the sidebar popup menu would result in the
VCLXWindow's VCLXWindow::getAccessibleContext menu
getting called, which calls VCLXWindow::CreateAccessibleContext
and the VCLXWindow would keep a reference to the
returned XAccessibleContext and dispose it when
the VLCXWindow itself gets disposed.
However, AccessibleFactory::createAccessibleContext
(called by VCLXWindow::CreateAccessibleContext)
doesn't actually create a new object for the
MenuFloatingWindow's accessible, but returns the
existing accessible object of the PopupMenu, which is
owned by the PopupMenu, not the MenuFloatingWindow,
s.a. previous commit

    Change-Id: Ia2931bee23204395e8b3396927acf4fa1d0f077c
    Author: Michael Weghorn <m.weghorn@posteo.de>
    Date:   Thu Dec 5 11:06:48 2024 +0000

        tdf#164093 tdf#157001 a11y: Improve menu window disposal

for more details.

Backtrace of how that accessible context was returned:

    1 `anonymous namespace'::AccessibleFactory::createAccessibleContext acc_factory.cxx 305 0x7fffbc160767
    2 VCLXWindow::CreateAccessibleContext vclxwindow.cxx 879 0x7fffc0b1bc67
    3 VCLXWindow::getAccessibleContext vclxwindow.cxx 2418 0x7fffc0b2670b
    4 AccTopWindowListener::HandleWindowOpened AccTopWindowListener.cxx 60 0x7fffe5c32ab6
    5 AccTopWindowListener::windowOpened AccTopWindowListener.cxx 119 0x7fffe5c3375e
    6 ``anonymous namespace'::VCLXToolkit::callTopWindowListeners'::`2'::<lambda_1>::operator() vclxtoolkit.cxx 2364 0x7fffc0af27ef
    7 comphelper::OInterfaceContainerHelper4<com::sun:⭐:awt::XTopWindowListener>::forEach<``anonymous namespace'::VCLXToolkit::callTopWindowListeners'::`2'::<lambda_1>> interfacecontainer4.hxx 349 0x7fffc0ae7f9e
    8 `anonymous namespace'::VCLXToolkit::callTopWindowListeners vclxtoolkit.cxx 2359 0x7fffc0afeaed
    9 `anonymous namespace'::VCLXToolkit::eventListenerHandler vclxtoolkit.cxx 2295 0x7fffc0b02492
    10 `anonymous namespace'::VCLXToolkit::LinkStubeventListenerHandler vclxtoolkit.cxx 2288 0x7fffc0afbdf6
    11 Link<VclSimpleEvent &,void>::Call link.hxx 111 0x7fffbfba33d3
    12 VclEventListeners::Call vclevent.cxx 47 0x7fffbfba35f1
    13 Application::ImplCallEventListeners svapp.cxx 733 0x7fffbfb76dbb
    14 vcl::Window::CallEventListeners event.cxx 229 0x7fffbf45f841
    15 vcl::Window::ImplSetReallyVisible window.cxx 1331 0x7fffbf566bad
    16 vcl::Window::ImplSetReallyVisible window.cxx 1344 0x7fffbf566c7d
    17 vcl::Window::Show window.cxx 2336 0x7fffbf56a8d1
    18 vcl::Window::Show window.cxx 2349 0x7fffbf56a9ce
    19 FloatingWindow::StartPopupMode floatwin.cxx 825 0x7fffbf46a702
    20 PopupMenu::Run menu.cxx 3018 0x7fffbf4a6f02
    ... <More>

When the MenuFloatingWindow gets disposed, its
VCLXWindow is also disposed. Since it incorrectly
assumes it (or its Window) owns the XAccessibleContext,
it disposes that as well:

    1 OAccessibleMenuBaseComponent::disposing accessiblemenubasecomponent.cxx 608 0x7fffbf300c82
    2 cppu::WeakComponentImplHelperBase::dispose implbase.cxx 104 0x7fffe199964a
    3 cppu::PartialWeakComponentImplHelper<com::sun:⭐:accessibility::XAccessibleContext2,com::sun:⭐:accessibility::XAccessibleEventBroadcaster>::dispose compbase.hxx 90 0x7fffdb8d1820
    4 VCLXWindow::dispose vclxwindow.cxx 938 0x7fffc0b24012
    5 UnoWrapper::WindowDestroyed unowrapper.cxx 302 0x7fffc0cfddc6
    6 vcl::Window::dispose window.cxx 220 0x7fffbf56e68f
    7 SystemWindow::dispose syswin.cxx 107 0x7fffbf515606
    8 FloatingWindow::dispose floatwin.cxx 225 0x7fffbf46b751
    9 MenuFloatingWindow::dispose menufloatingwindow.cxx 134 0x7fffbf4bd766
    10 VclReferenceBase::disposeOnce vclreferencebase.cxx 39 0x7fffbf7520d9
    11 VclPtr<vcl::Window>::disposeAndClear vclptr.hxx 207 0x7fffbf3f98d2
    12 PopupMenu::ImplExecute menu.cxx 2947 0x7fffbf4a0ee7
    13 PopupMenu::Execute menu.cxx 2834 0x7fffbf49c392
    14 MenuButton::ExecuteMenu menubtn.cxx 77 0x7fffbf639f1d
    15 MenuButton::MouseButtonDown menubtn.cxx 214 0x7fffbf63a847
    16 ImplHandleMouseEvent winproc.cxx 708 0x7fffbf57ca27
    17 ImplHandleSalMouseButtonDown winproc.cxx 2338 0x7fffbf57e1af
    18 ImplWindowFrameProc winproc.cxx 2683 0x7fffbf57fc07
    19 SalFrame::CallCallback salframe.hxx 312 0x7fffbf3443c6
    20 ImplHandleMouseMsg salframe.cxx 3415 0x7fffbc818e8f
    ... <More>

However, the Menu that actually owns the accessible may
still be alive, and then opening the menu again results
in an attempt to make use of the already disposed object,
triggering a crash due to a DisposedException being thrown:

    1   RaiseException                                            KERNELBASE                           0x7ff808e8b699
    2   CxxThrowException                                         VCRUNTIME140                         0x7fffef535267
    3   comphelper::OCommonAccessibleComponent::ensureAlive       accessiblecomponenthelper.cxx   141  0x7fffdb8d1937
    4   comphelper::OContextEntryGuard::OContextEntryGuard        accessiblecontexthelper.hxx     64   0x7fffbf2fb8eb
    5   comphelper::OExternalLockGuard::OExternalLockGuard        accessiblecontexthelper.hxx     81   0x7fffbf2fb948
    6   OAccessibleMenuBaseComponent::getAccessibleContext        accessiblemenubasecomponent.cxx 641  0x7fffbf301337
    7   VCLXAccessibleComponent::ProcessWindowChildEvent          vclxaccessiblecomponent.cxx     165  0x7fffc0a9596d
    8   VCLXAccessibleComponent::WindowChildEventListener         vclxaccessiblecomponent.cxx     124  0x7fffc0a96669
    9   VCLXAccessibleComponent::LinkStubWindowChildEventListener vclxaccessiblecomponent.cxx     114  0x7fffc0a957f6
    10  Link<VclWindowEvent &,void>::Call                         link.hxx                        111  0x7fffbf45f7d3
    11  vcl::Window::CallEventListeners                           event.cxx                       300  0x7fffbf45fe0c
    12  vcl::Window::ImplSetReallyVisible                         window.cxx                      1331 0x7fffbf566bad
    13  vcl::Window::ImplSetReallyVisible                         window.cxx                      1344 0x7fffbf566c7d
    14  vcl::Window::Show                                         window.cxx                      2336 0x7fffbf56a8d1
    15  vcl::Window::Show                                         window.cxx                      2349 0x7fffbf56a9ce
    16  FloatingWindow::StartPopupMode                            floatwin.cxx                    825  0x7fffbf46a702
    17  PopupMenu::Run                                            menu.cxx                        3018 0x7fffbf4a6f02
    18  PopupMenu::ImplExecute                                    menu.cxx                        3005 0x7fffbf4a1707
    19  PopupMenu::Execute                                        menu.cxx                        2834 0x7fffbf49c392
    20  MenuButton::ExecuteMenu                                   menubtn.cxx                     77   0x7fffbf639f1d
    ... <More>

To fix that, adjust winaccessibility's
AccTopWindowListener to no longer just use
the VCLXWindow for the accessible, but
get the vcl::Window for the VCLXWindow and
query it's actual XAccessible using
vcl::Window::GetAccessible().

This fixes the tdf#164093 crash. The problem of
tdf#157001 where items in the popup menu of Calc's organize
template dialog are only announced the first time the menu
is opened still remains for now, but is also somehow
related to the MenuFloatingWindow being disposed.
(No longer reproducible when no longer calling
the base class FloatingWindow::dispose from
MenuFloatingWindow::dispose in a local test,
still needs further analysis.)

Change-Id: Ic96d2c95128af144c7769aac40707299b1c80f8c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177889
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Added in:

    commit d66a97d562
    Date:   Thu Jan 12 08:29:24 2023 +0100

        loplugin:crosscast (clang-cl)

        > winaccessibility/source/service/AccTopWindowListener.cxx(47,36): error: suspicious dynamic cross cast from 'css::accessibility::XAccessible *' to 'VCLXAccessibleComponent *' [loplugin:crosscast]
        >     else if (auto pvclxcomponent = dynamic_cast<VCLXAccessibleComponent*>(pAccessible))
        >                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Change-Id: Iee7585dd2fa0d92af3be6b89d7d08326de3d1e7b
        Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145380
        Tested-by: Jenkins
        Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

AccTopWindowListener::HandleWindowOpened no longer does
that crosscast now, see

    Change-Id: Ic96d2c95128af144c7769aac40707299b1c80f8c
    Author: Michael Weghorn <m.weghorn@posteo.de>
    Date:   Thu Dec 5 14:07:52 2024 +0000

        tdf#164093 tdf#157001 wina11y: Use vcl::Window's actual XAccessible

Change-Id: Ifca76a5d519099f9cbe06f8bde606e01871363fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177891
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
- weld::Menu doesn't have base with weld::Widget
- use separate container, only one menu per WindowId
- first only send menu and cancel, when user activates
  option we will send another request and execute entry
  as menu can be blocking
- there is connect_activated way of async setup too

Change-Id: Iea03f82a91ecc19af67b91f85364675c119056ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177722
(cherry picked from commit efeb511607dacce991866bcf328c96a01ab594f9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177852
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
which causes problems on export to docx. Sanitize at the original
import.

Change-Id: I8b9fa86465c455fe872c41386889dc54e38eb9ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177904
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
In fact do not accept anything else than blanks after integer
portion for a fraction.

Change-Id: I29746bb7cd78ecc6a7810e8841bee748589a36e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177899
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
actualizacion automatica 2024-12-06
Some checks failed
Repo Lockdown / point-to-upstream (pull_request_target) Has been cancelled
Details
545943be5c
iapz merged commit 02cf82760e into master 2024-12-06 00:05:45 -06:00
iapz deleted branch actualizacion-master-2024-12-06 2024-12-06 00:05:46 -06:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: strepsirrhini/office-gobmx#5
No description provided.
Delete branch "actualizacion-master-2024-12-06"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?