Now when version 25.8 is in development, and the drop of legacy Windows
versions was announced in release notes.
Change-Id: Iefda63a29cafe40aec78d149067bdd7a3f20cffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178025
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This is independent of the selection.
(For selection, there is weld::TreeView::select
and weld::TreeView::get_selected_index instead.)
Change-Id: I3698a080cebaf4411740b0e7a95c54743e84d881
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178024
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Rename weld::TreeView member + methods to clarify
that these are about selection changes:
* m_aChangeHdl to m_aSelectionChangedHdl,
* signal_changed to signal_selection_changed
* connect_changed to connect_selection_changed
In GtkInstanceTreeview, also rename the
related methods calling signal_selection_changed
accordingly for consistency.
Change-Id: I299d7930484677395a0bdd0ff105df18688f2e04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178023
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... to avoid own mutexes in own name container implementation.
Change-Id: I29ff6ef987154359c35d0628d529b0606ef08c5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177637
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When a frame is hidden, don't consider it when evaluating keep-with-next
attributes - this was the case for content in hidden sections before
commit 0c96119895
~SwFrameNotify() invalidating position of hidden frame with keep
attribute causes layout loops.
Also skip hidden frames in SwFlowFrame::IsKeepFwdMoveAllowed(),
SwFlowFrame::CheckKeep(), SwFlowFrame::IsPrevObjMove(),
SwFlowFrame::MoveBwd(), CalcContent().
Change-Id: I68556ba0a8e016d962399f3ce199e5eda0378867
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177975
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Open the bugdoc, go to the page after the section break, there is a top
margin for the first paragraph there in Word, but not in Writer.
This went wrong in commit abd90828cf
(tdf#160952 sw: ignore top margin of para on non-first pages with newer
DOCX, 2024-05-14), where it seemed that all implicit and explicit page
breaks want to ignore that top margin for the first paragraph.
Turns out this is more complex: implicit breaks and page breaks should
be followed by an ignore, but not paragraphs after "section break (next
page)". So restore the margins for the RES_PAGEDESC, but continue to
have them for RES_BREAK & implicit breaks.
Change-Id: If1fcf3077b81a705d3587bdae422dcfa16f1c17c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177973
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
When live resizing a window, replacing the CAMetalLayer with each
resize event repaints the window's background which causes a
noticeable flicker. So reuse any existing CAMetalLayer already
assigned to the native view.
Change-Id: I03bda5f0d40b84606b6602961e5f0d3b0dfcc6ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177921
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
The size of the value field is now set to 5 rows.
Change-Id: I808ffbb64d71a0707857cf80d1c0b73419ac7b90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177893
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Commit c83d241eff "tdf#154933 Rename "Text
Body" para style to "Body Text"" introduced a regression when importing
certain ODF documents, but the problem is actually pre-existing.
What happens is that first the built-in "Text body" style is created,
and then a non-built-in style with the same translated name as "Text
body" is imported, and instead of creating a new style, the built-in one
is found and used, and so its properties are overwritten.
The root cause is that SwStyleNameMapper::FillProgName() and in
particular SwStyleNameMapper::FillUIName() are defined poorly, ever
since they were introduced in 2001 in commit
4fbc9dd48b
It becomes obvious relatively quickly that the way style names work is
that at the UNO API level, the "ProgName" (internal, non-localised)
names are used, and at the core document level, the "UIName" (localised)
names are used.
This is in itself questionable - why is the translation from ProgName to
UIName not done in the UI? - but also very expensive to change now.
So then the UNO services are responsible for translating between
ProgName and UIName.
But the 2 functions don't do that properly; both need to check if the
given name is a known ProgName *or* a known UIName, and rename it in
case it collides with a known target name; also the 2 functions need to
cancel each other out, not add " (user)" at the end in both directions.
Fixing this causes numerous tests to fail, due to:
1. the UNO services calling themselves with already converted style
names, which are then translated a second time, which fails now.
(or calling the wrong function like SwXStyleFamily::getByIndex())
2. many tests call the UNO API with UINames instead of ProgNames
3. somehow the writerfilter import is also changed, causing failures in
e.g. testTdf113182 and testTdf104492
4. buggy code elsewhere (lcl_getUsedPageStyles()), problem similar to
1., for PageDescs
5. potentially more buggy code yet to be discovered (definitely table
styles, forgot which test that was)
So limit this fix for now to only paragraph styles, and don't do it in
writerfilter import, now at least sw.check passes.
Change-Id: I5cbdf3e174622e83f9af8787c3671b88c0e37bac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177858
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Tested-by: Jenkins
V1048 The 'eAggFunc' variable was assigned the same value. Will be assigned after the switch.
Change-Id: I21d4cb4b0e7427bea56598476ca176cc0a4f7124
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175902
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Declare support for the "Insert Breaks"
"File" -> Printer Settings" -> "Properties" dialog.
This means that native Qt widgets are used for that dialog
now when using the qt5 or qt6 VCL plugin and starting LO with
environment variable SAL_VCL_QT_USE_WELDED_WIDGETS=1 set.
Since this dialog contains tab pages, their .ui files
need to be declared as supported as well.
Change-Id: Ia4360eebf3fed6ab5f78510c866a1703b0db8998
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177923
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The current item and the selected item(s) are
not necessarily the same.
Looking into the gtk and VCL implementations,
weld::TreeView::signal_changed is called
when the selection (not the current item) changes, so
connect to the QItemSelectionModel::selectionChanged signal
instead of the QItemSelectionModel::currentChanged one
in the Qt implementation.
At the point in time that the QItemSelectionModel::selectionChanged
signal gets emitted, QItemSelectionModel::selectedIndexes
returns the newly selected indices while that was not
yet the case with QItemSelectionModel::currentChanged.
For the "Device" tab in the "File" -> "Printer Settings" -> "Properties"
dialog (for which support will be added in an upcoming commit),
this resulted in the PPD values (in the tree view
on the right) not being shown for the actually selected PPD
option/key (in the left tree view), but for the
one selected previously.
(See RTSDevicePage::SelectHdl for the logic filling
the tree view with items, which gets triggered when
weld::TreeView::signal_changed gets called.)
Change-Id: I31ec5aaaa47cd3d4704f25086b24645fb708be0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177922
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Similar to the check done in SwEditWin::MouseButtonDown.
Change-Id: I1a1b8966502a6b1557d424f28cfc1c1ecdf4b65e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177930
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Due to formatting, grapheme clusters can possibly be split across
multiple layouts. Layouts containing split grapheme clusters are created
by laying out the complete string, and extracting only the necessary
glyphs based on source codepoint index.
This approach is good enough for most diacritic cases, but it cannot
handle certain substitution cases where glyphs with advances would be
interleaved with other layouts. Sub-layouts must be contiguous.
This change introduces code to disable grapheme cluster splitting in
these cases that cannot be handled correctly.
Change-Id: I122abbf9c3f8a5efa4c72ad47991d0ad9ff8a8c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177927
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Used e.g. in RTSDevicePage::FillValueBox
(i.e. in the "File" -> "Printer Settings" -> "Properties"
dialog).
Change-Id: Ice39b266b366a6fd6b37b6ece28cee529990dc80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177909
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
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
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>
- 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>
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>
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>
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
... 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>
... 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>
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
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>
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
