Also avoid std::random_device it doesn't work in a COOL
kit process.
Change-Id: Ie2d063611a73e734afd92d6fd779f34a2f316230
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167070
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
There doesn't appear to be an accurate and complete documentation of all
the Word built-in style names, but fortunately Word writes them all into
styles.xml in a w:latentStyles element anyway.
It turned out that a lot of the Writer built-in style names here were
obsoleted by renaming and did not match any more.
Change-Id: Ic69785a34524f667b83a06a267715b2c8b0165d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167242
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The 2nd page of the bugdoc has a single paragraph, with a non-zero top
margin. This is ignored in Word, but wasn't ignored in Writer.
Experimenting with the document, it looks like old Word files also don't
ignore this top margin: it started when the compat mode is upgraded
(from binary DOC or Word 2010) to Word 2023 or newer. Also the top
margin is only ignored for the first paragraph on the page, and only in
case it's not on the first page.
Fix the problem by introducing a new SwFrame::IsCollapseUpper() function
to decide if the upper margin should be collapsed or not, and then by
using it in SwFlowFrame::CalcUpperSpace() at one place where we read the
top margin from the doc model. Take advantage of the fact that we have
related, existing compat flags that tell us if we're in "Word >= 2013"
compat mode: see e.g. GetFlyAnchorBottom(), which explains
DocumentSettingId::TAB_OVER_MARGIN is a good indicator that this is a
"Word <= 2010" document. Also, DocumentSettingId::TAB_OVER_SPACING is an
indicator that this is a Word document, so we want the "TabOverSpacing
&& !TabOverMargin" case.
This doesn't change all reads of the upper spacing of a text node, but
is enough to avoid the unwanted top spacing, as demonstrated by the
bugdoc.
Change-Id: Ibdebdf5f0555256a0b6ed85d07079f14ef69a576
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167252
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Since writerfilter moved into sw in 24.8,
this section can be seriously optimized.
Change-Id: I6a228b1a910181c38ba5c8faf9566954fffc47fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166988
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
shaves 30% off the startup time for me.
Change-Id: Ibabb2a6b283243aaaaafb8257e99e82e2ef112c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167100
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Also remove outdated comment related to RTL_CONSTASCII_STRINGPARAM
(only the first line was removed in the past)
Change-Id: Iebef1bf83ab049a96c846e714cb700df4dacd878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167233
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Similar to how the previous
Change-Id: I00e62016ced2fbb8796960671f5e58a3ceac4b29
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon May 6 14:44:36 2024 +0200
tdf#160806 tdf#160837 gtk3 a11y: Drop handling of some VclEventIds
dropped handling for `VclEventId::WindowGetFocus`
and `VclEventId::ObjectDying` in the gtk3 a11y bridge,
do the same for `VclEventId::ToolboxButtonStateChanged`.
And drop `VclEventId::ObjectDying` completely, as the
gtk3 a11y bridge was the only place processing it.
That event and the handling had been introduced in
commit 3b40f50234
Author: Ivo Hinkelmann <ihi@openoffice.org>
Date: Tue Feb 5 11:30:51 2008 +0000
INTEGRATION: CWS fwk83_SRC680 (1.7.186); FILE MERGED
2008/01/30 12:40:39 obr 1.7.186.2: fix for fedora tinderbox (64bit)
2008/01/15 23:49:28 obr 1.7.186.1: #i70872# create wrapper for toolbox items that change state
commit a1cbbd113d
Author: Ivo Hinkelmann <ihi@openoffice.org>
Date: Tue Feb 5 11:30:25 2008 +0000
INTEGRATION: CWS fwk83_SRC680 (1.51.160); FILE MERGED
2008/01/14 14:35:26 cd 1.51.160.1: #i70872# Added VCLEVENT_TOOLBOX_BUTTONCHANGED to notify accessibility implementation that an action happens to a toolbox button
commit 3f1afd1788
Author: Ivo Hinkelmann <ihi@openoffice.org>
Date: Tue Feb 5 11:29:57 2008 +0000
INTEGRATION: CWS fwk83_SRC680 (1.2.262); FILE MERGED
2008/01/14 14:35:26 cd 1.2.262.1: #i70872# Added VCLEVENT_TOOLBOX_BUTTONCHANGED to notify accessibility implementation that an action happens to a toolbox button
to ensure that an a11y object is created for toolbar
buttons whose state changes, so that the corresponding
a11y events are forwarded to the platform layer, see
the referenced OOo bug #i70872# [1] for more details.
This seems to be no longer necessary.
By now, at least the scenario of toggling the
bold/italics/underline status of text is
announced just fine by Orca 46.1-1 on Debian
testing with this change in place.
(FWIW, tdf#123864 and the corresponding commits are more
recent tickets/commits related to the topic.)
Like for the above-mentioned change,
dropping that handling addresses another case where the
work window/root pane's a11y object when walking up
the a11y hierarchy would be problematic, as it doesn't
take into account the GtkWidget hierarchy.
Sample backtrace of how the "problematic" a11y object
was created (frame 1 below is the one where the a11y object
with role root pane is created.)
1 atk_object_wrapper_new atkwrapper.cxx 983 0x7f620365672b
2 atk_object_wrapper_ref atkwrapper.cxx 948 0x7f62036560a0
3 atk_object_wrapper_new atkwrapper.cxx 1000 0x7f6203656952
4 atk_object_wrapper_ref atkwrapper.cxx 948 0x7f62036560a0
5 atk_object_wrapper_new atkwrapper.cxx 1000 0x7f6203656952
6 atk_object_wrapper_ref atkwrapper.cxx 948 0x7f62036560a0
7 atk_object_wrapper_new atkwrapper.cxx 1000 0x7f6203656952
8 atk_object_wrapper_ref atkwrapper.cxx 948 0x7f62036560a0
9 create_wrapper_for_child atkutil.cxx 359 0x7f620364c740
10 handle_toolbox_buttonchange atkutil.cxx 376 0x7f620364c1ef
11 WindowEventHandler atkutil.cxx 438 0x7f620364bd7f
12 Link<VclSimpleEvent&, void>::Call link.hxx 111 0x7f620dfd4ef8
13 VclEventListeners::Call vclevent.cxx 46 0x7f620dfd3f1a
14 Application::ImplCallEventListeners svapp.cxx 725 0x7f620df96b0d
15 vcl::Window::CallEventListeners event.cxx 225 0x7f620d59f6ee
16 ToolBox::SetItemState toolbox2.cxx 1197 0x7f620d6afd81
17 ToolBox::CheckItem toolbox.hxx 515 0x7f6214502c53
18 (anonymous namespace)::PopupMenuToolbarController::statusChanged popuptoolbarcontroller.cxx 180 0x7f621454205d
19 (anonymous namespace)::GenericPopupToolbarController::statusChanged popuptoolbarcontroller.cxx 373 0x7f6214540855
20 SfxDispatchController_Impl::addStatusListener unoctitm.cxx 797 0x7f6213090e95
21 SfxOfficeDispatch::addStatusListener unoctitm.cxx 279 0x7f6213090ade
22 svt::ToolboxController::bindListener toolboxcontroller.cxx 558 0x7f620fe9fbce
23 svt::ToolboxController::update toolboxcontroller.cxx 235 0x7f620fe9f207
24 framework::ToolBarManager::UpdateControllers toolbarmanager.cxx 726 0x7f62145b0f25
25 framework::ToolBarManager::AsyncUpdateControllersHdl toolbarmanager.cxx 2291 0x7f62145bdbfc
26 framework::ToolBarManager::LinkStubAsyncUpdateControllersHdl toolbarmanager.cxx 2278 0x7f62145aff9d
27 Link<Timer *, void>::Call link.hxx 111 0x7f620dfbc618
28 Timer::Invoke timer.cxx 75 0x7f620dfbc46c
29 Scheduler::CallbackTaskScheduling scheduler.cxx 509 0x7f620df5fa08
30 SalTimer::CallCallback saltimer.hxx 54 0x7f620368b566
31 sal_gtk_timeout_dispatch gtkdata.cxx 733 0x7f620368a573
32 ?? 0x7f62097110d9
33 ?? 0x7f6209714317
34 g_main_context_iteration 0x7f6209714930
35 GtkSalData::Yield gtkdata.cxx 405 0x7f62036888ef
36 GtkInstance::DoYield gtkinst.cxx 435 0x7f620368dd73
37 ImplYield svapp.cxx 378 0x7f620df94dfc
38 Application::Yield svapp.cxx 466 0x7f620df9470b
39 Application::Execute svapp.cxx 353 0x7f620df944a2
40 desktop::Desktop::Main app.cxx 1615 0x7f62171254fc
41 ImplSVMain svmain.cxx 229 0x7f620dfb760e
42 SVMain svmain.cxx 261 0x7f620dfb9659
43 soffice_main sofficemain.cxx 93 0x7f62171a7eb3
44 sal_main main.c 51 0x56162eceea5d
45 main main.c 49 0x56162eceea37
[1] https://bz.apache.org/ooo/show_bug.cgi?id=70872
Change-Id: I7409806071a00f32b201b08a831dc6941f072047
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167209
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Drop custom handling for VCL events `VclEventId::WindowGetFocus`
and `VclEventId::ObjectDying` in the gtk3 a11y bridge.
In my understanding, the a11y bridge should not have to
handle any of these by itself, but all relevant a11y
events should be forwarded to the a11y listener
as an appropriate `AccessibleEventObject` and be handled
by the a11y event listener instead, see
`AtkListener::notifyEvent` for the gtk3 implementation.
In a quick test with Orca, I didn't notice anything not being
announced anymore with this change in place.
If something is still not announced due to this change, a
proper fix is likely to make sure that a proper a11y event
is emitted and handled in `AtkListener::notifyEvent` instead.
Note how `VCLXAccessibleComponent::ProcessWindowEvent` already
handles the `VclEventId::WindowGetFocus` and
`VclEventId::ObjectDying` window events. This (or
a corresponding override in a subclass) and
`VclEventId::ObjectDying` are potentially good places to
start analysis if this change here results in any regressions.
Dropping this custom handling also fixes one problematic
way that an accessible object would be created for the
work window/root panel (e.g. in Writer) from the corresponding
XAccessible independent of the corresponding GTK Widget hierarchy,
thus breaking the a11y hierarchy (ascending the tree doesn't
work, see tdf#160806).
This could be observed by starting LO Writer with the gtk3 VCL
plugin first, then start Accerciser.
Printing the a11y info for the parent of the object with role
root pane as shown in Accerciser:
In [1]: acc.parent
Out[1]: <Atspi.Accessible object at 0x7f1f0f5b7780 (AtspiAccessible at 0x41f9c60)>
In [2]: acc.parent.role
Out[2]: <enum ATSPI_ROLE_FRAME of type Atspi.Role>
In [3]: acc.parent.role
Out[3]: <enum ATSPI_ROLE_FRAME of type Atspi.Role>
Selecting the object shown as the parent in Accerciser's tree
of LO's a11y hierarchy shows that this is not the same object:
In [4]: acc
Out[4]: <Atspi.Accessible object at 0x7f1f05f92100 (AtspiAccessible at 0x2d45c80)>
In [5]: acc.role
Out[5]: <enum ATSPI_ROLE_PANEL of type Atspi.Role>
and consequently, the first child of that accessible doesn't
report the accessible itself as its parent:
In [6]: acc.get_child_at_index(0).parent == acc
Out[6]: False
The commit message of
commit 252b1591d5
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Apr 30 15:30:52 2024 +0200
tdf#159369 tdf#160806 tdf#160837 gtk3 a11y: Don't skip parents one way
has some more background information.
Extra local change in place showing where the accessible object gets
created (used for analysis with rr):
diff --git a/vcl/unx/gtk3/a11y/atkwrapper.cxx b/vcl/unx/gtk3/a11y/atkwrapper.cxx
index db0aa1dbc907..c73d28987f26 100644
--- a/vcl/unx/gtk3/a11y/atkwrapper.cxx
+++ b/vcl/unx/gtk3/a11y/atkwrapper.cxx
@@ -977,6 +977,10 @@ atk_object_wrapper_new( const css::uno::Reference< css::accessibility::XAccessib
AtkObject* atk_obj = ATK_OBJECT(pWrap);
atk_obj->role = mapToAtkRole(xContext->getAccessibleRole(), xContext->getAccessibleStateSet());
+ // NOTE: the object of interest is root pane, breaks the a11y hierarchy
+ // as it reports wrong parent
+ if (atk_obj->role == ATK_ROLE_ROOT_PANE)
+ SAL_WARN("vcl.gtk", "Creating wrapper for root pane");
atk_obj->accessible_parent = parent;
ooo_wrapper_registry_add( rxAccessible, atk_obj );
Sample backtrace of how the problematic accessible object
got created without this commit in place:
1 atk_object_wrapper_new atkwrapper.cxx 983 0x7fb5dda5ae8b
2 atk_object_wrapper_ref atkwrapper.cxx 948 0x7fb5dda5a800
3 atk_wrapper_notify_focus_change atkutil.cxx 47 0x7fb5dda4cab0
4 handle_get_focus atkutil.cxx 451 0x7fb5dda4debd
5 WindowEventHandler atkutil.cxx 512 0x7fb5dda4d9e3
6 Link<VclSimpleEvent&, void>::Call link.hxx 111 0x7fb5e81d4ef8
7 VclEventListeners::Call vclevent.cxx 46 0x7fb5e81d3f1a
8 Application::ImplCallEventListeners svapp.cxx 725 0x7fb5e8196b0d
9 vcl::Window::CallEventListeners event.cxx 225 0x7fb5e779f6ee
10 vcl::Window::PreNotify event.cxx 70 0x7fb5e779f58c
11 SystemWindow::PreNotify syswin.cxx 245 0x7fb5e788e470
12 vcl::Window::CompatPreNotify window.cxx 3941 0x7fb5e790cddd
13 ImplCallPreNotify winproc.cxx 69 0x7fb5e791d061
14 vcl::Window::ImplGrabFocus mouse.cxx 383 0x7fb5e782ffc5
15 vcl::Window::GrabFocus window.cxx 2988 0x7fb5e78fa027
16 vcl::Window::ImplAsyncFocusHdl winproc.cxx 2061 0x7fb5e7923386
17 vcl::Window::LinkStubImplAsyncFocusHdl winproc.cxx 2035 0x7fb5e792318d
18 Link<void *, void>::Call link.hxx 111 0x7fb5e792c298
19 ImplHandleUserEvent winproc.cxx 2287 0x7fb5e7927f79
20 ImplWindowFrameProc winproc.cxx 2851 0x7fb5e7924930
21 SalFrame::CallCallback salframe.hxx 312 0x7fb5e85a0310
22 SalGenericDisplay::ProcessEvent gendisp.cxx 66 0x7fb5e85cae6f
23 SalUserEventList::DispatchUserEvents(bool)::$_0::operator()() const salusereventlist.cxx 119 0x7fb5e80b49bd
24 SalUserEventList::DispatchUserEvents salusereventlist.cxx 120 0x7fb5e80b4864
25 SalGenericDisplay::DispatchInternalEvent gendisp.cxx 51 0x7fb5e85cadc5
26 call_userEventFn gtkdata.cxx 824 0x7fb5dda8e216
27 ?? 0x7fb5e47110d9
28 ?? 0x7fb5e4714317
29 g_main_context_iteration 0x7fb5e4714930
30 GtkSalData::Yield gtkdata.cxx 405 0x7fb5dda8ccef
31 GtkInstance::DoYield gtkinst.cxx 435 0x7fb5dda92173
32 ImplYield svapp.cxx 378 0x7fb5e8194dfc
33 Application::Yield svapp.cxx 466 0x7fb5e819470b
34 Application::Execute svapp.cxx 353 0x7fb5e81944a2
35 desktop::Desktop::Main app.cxx 1615 0x7fb5f13254fc
36 ImplSVMain svmain.cxx 229 0x7fb5e81b760e
37 SVMain svmain.cxx 261 0x7fb5e81b9659
38 soffice_main sofficemain.cxx 93 0x7fb5f13a7eb3
39 sal_main main.c 51 0x55b83ad6da5d
40 main main.c 49 0x55b83ad6da37
Sample backtrace for how the root pane a11y object is created for the
good case, i.e. the case where the root pane's parent is set properly
as it uses the GTK widget hierarchy (backtrace obtained from an rr run
when first starting Accerciser, then LO, with master as of
7a895ec420 + the same local change as mentioned
above):
1 atk_object_wrapper_new atkwrapper.cxx 983 0x7f3799a5b48b
2 wrapper_factory_create_accessible atkfactory.cxx 83 0x7f3799a2c9c1
3 ooo_fixed_get_accessible atkfactory.cxx 95 0x7f3799a2c6d2
4 ?? 0x7f37993ec4c8
5 ?? 0x7f3798c536d3
6 ?? 0x7f379f9110d9
7 ?? 0x7f379f914317
8 g_main_context_iteration 0x7f379f914930
9 GtkSalData::Yield gtkdata.cxx 405 0x7f3799a8d2df
10 GtkInstance::DoYield gtkinst.cxx 435 0x7f3799a92743
11 ImplYield svapp.cxx 378 0x7f37a4194dfc
12 Application::Yield svapp.cxx 466 0x7f37a419470b
13 Application::Execute svapp.cxx 353 0x7f37a41944a2
14 desktop::Desktop::Main app.cxx 1615 0x7f37ad3254fc
15 ImplSVMain svmain.cxx 229 0x7f37a41b760e
16 SVMain svmain.cxx 261 0x7f37a41b9659
17 soffice_main sofficemain.cxx 93 0x7f37ad3a7eb3
18 sal_main main.c 51 0x560d4a1f4a5d
19 main main.c 49 0x560d4a1f4a37
Similar changes for other events will follow.
(Keeping them separate for easier bibisecting/analysis if any
of those changes causes regressions.)
Change-Id: I00e62016ced2fbb8796960671f5e58a3ceac4b29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167208
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`atk_focus_tracker_notify` takes care of sending an
"AtkObject:focus-event" event for the given object.
However, both, `atk_focus_tracker_notify` and the "AtkObject:focus-event"
ATK event (which triggers a "focus" AT-SPI event) are
deprecated, quoting [1]:
> Focus tracking has been dropped as a feature to be implemented by ATK
> itself. As AtkObject::focus-event was deprecated in favor of a
> AtkObject::state-change signal, in order to notify a focus change on
> your implementation, you can use atk_object_notify_state_change()
> instead.
Move the existing call to `atk_object_notify_state_change` up and
use instead of the deprecated function.
For the example of the "Print" button in
Writer's standard toolbar, it can now be
seen that a "object:state-changed:focused"
instead of a "focus" event is received with
a corresponding listener when tabbing to
the button and then further:
Before:
88.7 focus:(0, 0, 0)
source: [push button | Print]
application: [application | soffice]
88.7 object:state-changed:focused(1, 0, 0)
source: [push button | Print]
application: [application | soffice]
89.4 object:state-changed:focused(0, 0, 0)
source: [push button | Print]
application: [application | soffice]
After:
80.0 object:state-changed:focused(1, 0, 0)
source: [push button | Print]
application: [application | soffice]
80.0 object:state-changed:focused(1, 0, 0)
source: [push button | Print]
application: [application | soffice]
80.8 object:state-changed:focused(0, 0, 0)
source: [push button | Print]
application: [application | soffice]
The first event is the one emitted fromt this place,
the others are from elsewhere.
This also already shows that duplicate events are
sent. Eliminating those which also cause
other problems is planned in upcoming steps.
[1] https://docs.gtk.org/atk/func.focus_tracker_notify.html
Change-Id: Ieb9d25445b620681b01b887c0c120c80a43379ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167207
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Don't use and idle to call the (deprecated) ATK focus tracker,
but do so right away.
Since this is no longer called in an idle, the SolarMutexGuard
should also no longer be needed, so drop it.
It's not clear why the focus event was handled in an
idle ever since
commit 3b5c378706
Author: Rüdiger Timm <rt@openoffice.org>
Date: Fri May 5 09:58:25 2006 +0000
INTEGRATION: CWS atkbridge (1.1.2); FILE ADDED
2006/04/27 14:47:54 obr 1.1.2.17: #134576# move focus clearing code to atkwindow.cxx
2006/04/27 08:18:11 obr 1.1.2.16: #134571# toolbox items are no VCL windows
2006/03/31 12:19:40 obr 1.1.2.15: #i63583# eliminated warnings
2006/03/03 11:07:09 obr 1.1.2.14: #i47890# fixed a crash when event source does not implement XAccessibleContext
2006/03/01 11:04:11 obr 1.1.2.13: #i47890# recursivly attach listeners to windows of type TREELISTBOX
2006/02/16 11:07:11 obr 1.1.2.12: #i47890# ORoadmapIDHyperLabel is derived from FixedText
2006/02/15 12:42:56 obr 1.1.2.11: #i47890# simulate focus events for page tabs
2006/02/07 09:26:21 obr 1.1.2.10: #i47890# reduce amount of focus notifications
2006/01/12 13:56:14 obr 1.1.2.9: #i47890# Solaris compile fixes
2006/01/05 14:06:32 obr 1.1.2.8: #i47890# override toolkit name and version and reworked bridge initialization
2005/11/16 15:57:57 obr 1.1.2.7: fixed for menu state ARMED only valid during notification
2005/10/24 07:36:05 obr 1.1.2.6: #i47890# reset focused object on WINDOW_DEACTIVATE
2005/10/20 11:57:32 obr 1.1.2.5: #i47890# initially set name and description + disabled some tracing
2005/10/20 07:09:12 obr 1.1.2.4: #i47890# made cxx files standalone, avoid queryInterface on each API call and demacrofied try/catch to include appropriate warnings
2005/09/28 07:24:13 obr 1.1.2.3: #i47890# changed ref-counting/life cycle once again, adjust tree and role of dialogs and filter sub-menu windows
2005/09/26 11:01:01 obr 1.1.2.2: #i47890# reworked lifecycle of atk wrapper objects
2005/06/14 13:57:24 obr 1.1.2.1: #i47890# global focus event listening stuff
With this in place, watching for "object:focus" events in
Accerciser still shows such an event when e.g. tabbing
through the standard toolbar in Writer. Example for when
the "Save" button receives focus:
37.9 focus:(0, 0, 0)
source: [push button | Save]
application: [application | soffice]
This is one step to port from the use of that deprecated
focus tracker and clean up a11y event handling in the gtk3 VCL plugin.
(Take one step at a time to keep the scope of the changes clearer
and simplify identifying causes of any potential regressions.)
(`git show --ignore-space-change` helps to see the
"actual change" more clearly).
Change-Id: Ia71b70bdf5d9db8fbb389f3c7366af48ee723af7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167206
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Revert "[API CHANGE] Remove deprecated Storage config item"
This reverts commit 3cee7edeb3.
As documented in the bug report, the config item is still used.
Thus, remove the deprecation notice, too.
Change-Id: Ia9beefe8e98bce8d70c546d27999d81c5cc9fd62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166904
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
.uno:OpenRemote command is not available (e.g disabled in a config file).
We also hide the Open remote file (and other) buttons in the Menubar
if they are settled to disable.
Change-Id: Ieb45c63b5d6aaf81d0eb7fa8947a9e109bee86f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167040
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
otherwise we might hit the assert inside the UIObjectUnoObj
constructor
Change-Id: I546964c0ec21bf4f874825dfd7dc11fc99ace502
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167099
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Somewhere in the tens of thousands of selected fill cells,
the size of the VirtualDevice exceeds 1 GB of pixels. But
Skia, at least on macOS, will fail to create a surface.
Even if there is ample free memory, Skia/Raster will fail.
The second problem is that even if you disable Skia, the
crash is just delayed when a BitmapEx is created from the
VirtualDevice and malloc() fails.
Since this data flavor really triggers one or more system
memory limits, lower the resolution of the bitmap by keeping
the VirtualDevice pixel size within an arbitrary number of
pixels.
Note: the artibrary "maximum number of pixels" limit that
that Skia can handle may need to be raised or lowered for
platforms other than macOS.
Change-Id: Ie087f2db152470aa70521fbe5fe6c7cedd8504af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167145
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Adapt SwGetRefFieldType::FindAnchor() to search for SwTextCharFormat,
and ApplyClonedTOCStylesToXText() to replace "CharStyleName".
Works for the "Intensive Hervorhebung" field in bugdoc.
Change-Id: Iee126eeb4cc2ff1c570941e3beefd93527c56fee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167098
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
* Handle STYLEREF style the same way as TOC style on import.
* Word 2013 does not uppercase the first letter
("Überschrift 1" -> "berschrift1") and there doesn't
appear to be any justification why the code does that.
* The style that's applied is actually the display style name
so convert from source's m_sConvertedStyleName.
* Change the logic in DomainMapper_Impl::ConvertTOCStyleName() to
explicitly check and clone only known built-in Word styles, which are
the ones that are translated.
* This requires some refactoring, and to add the built-in styles in the
bugdoc to the "StyleNameMap", which is probably still incomplete...
* Exporting to DOCX appears to work without changes.
* Somehow this causes the testFDO77715 to have an outlinelevel of 1 on
the TOC paragraphs now, but that turns out to be a bugfix.
Change-Id: I73bc1d1819e5cecbba2fef9cd6d290682a02a638
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167097
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
- Initializing some dialogs at the startup of Options
makes it opening very slow on some low-power systems.
- This patch removes this initialization. This means,
all dialogs will be initialized at the time of search.
Therefore, we should wait a bit longer when typing
on the search bar to get the results...
- remove the default parameter "nNumberOfNode" from
initializeFirstNDialog()
- rename initializeFirstNDialog() to initializeAllDialogs()
Change-Id: I4fd9c5673f7edecfe6a6621b6018d5d405f112a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167023
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Moritz Duge <moritz.duge@allotropia.de>
"Since LibreOffice 5.3: Throwing this exception will only prevent termination. Exiting LibreOffice will close all the windows but the process will keep running."
Currently, the behavior is different, because not only is LibreOffice
prevented from terminating, but the last document cannot be closed either. The expected behavior is all windows should be closed, but the
process should be kept running when using a TerminationVetoException.
Change-Id: I8764aefccc4c9feec3ee0e45a54bf0aebcf16c5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167194
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
Only Table of Contents has level settings, the level is always 0 for the
other ToX types, which erroneously excludes nodes (as can be seen with
testFDO77715 failing with upcoming tdf#160402 bugfix).
(regression from commit 5c04c44742)
Change-Id: Iec1c2b8eaba0ad20b2ad7d8c6b20603315a7a83d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167096
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
