FontSizeMenuController::fillPopupMenu() built a printer and a font list
using it. Neither were used after the change from
pFontList->GetSizeAry() to FontList::GetStdSizeAry().
This construction ran once per context menu activation where it runs
through the printer driver on Windows. Hence, the delay was not present
on Linux.
Change-Id: Ia0d9bd6b789f6b99437e97373421cb13a744a9da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210516
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
That Java a11y test has been disabled since
commit d595547fa6
Author: Vladimir Glazounov <vg@openoffice.org>
Date: Tue Oct 23 08:38:02 2007 +0000
INTEGRATION: CWS unoapi1 (1.2.440); FILE MERGED
2007/10/15 15:04:34 cn 1.2.440.3: #i79479# update Lists
2007/10/15 09:27:54 cn 1.2.440.2: #i79479# update Lists
2007/08/24 15:17:25 cn 1.2.440.1: #i79479# updateLists
. As the comment in qadevOOo/tests/java/mod/_toolkit/AccessibleListBox.java
says, it would try to run the hyperlink dialog and then
find various widgets using the a11y API. However, assumptions
that the test has do not match what widgets and corresponding
a11y implementations would be relevant for that dialog
today.
The test can be seen failing by enabling it locally
like this
--- a/toolkit/qa/unoapi/toolkit_1.sce
+++ b/toolkit/qa/unoapi/toolkit_1.sce
@@ -21,7 +21,7 @@
#i86008 -o toolkit.AccessibleComboBox
-o toolkit.AccessibleDropDownComboBox
#i86110 -o toolkit.AccessibleEdit
-#i86110 -o toolkit.AccessibleList
+-o toolkit.AccessibleList
#i86110 -o toolkit.AccessibleListItem
-o toolkit.AccessibleMenu
-o toolkit.AccessibleMenuBar
and then running `make JunitTest_toolkit_unoapi_1`.
Just drop the test altogether.
If there should be a relevant test again in the future,
writing a new (C++, see [1]) one from scratch seems more
promising than having to deal with this outdated and disabled
test.
Dropping it also prepares for more upcoming vcl a11y changes
that would break even more assumptions that the test makes.
This commit is similar to the previous
Change-Id: Idbd01f92c78cd78005b306114c53f9946fa4d35f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Sep 1 16:28:30 2026 +0200
a11y tests: Drop obsolete, long disabled AccessibleListBox Java test
, but now for the AccessibleList test.
[1] https://wiki.documentfoundation.org/Development/Accessibility_Unit_Tests
Change-Id: I1e0469f8f265d564cdcaf81aa1bdc8e718e49a26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210349
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
That Java a11y test has been disabled since
commit d595547fa6
Author: Vladimir Glazounov <vg@openoffice.org>
Date: Tue Oct 23 08:38:02 2007 +0000
INTEGRATION: CWS unoapi1 (1.2.440); FILE MERGED
2007/10/15 15:04:34 cn 1.2.440.3: #i79479# update Lists
2007/10/15 09:27:54 cn 1.2.440.2: #i79479# update Lists
2007/08/24 15:17:25 cn 1.2.440.1: #i79479# updateLists
. As the comment in qadevOOo/tests/java/mod/_toolkit/AccessibleListBox.java
says, it would try to run the hyperlink dialog and then
find various widgets using the a11y API. However, assumptions
that the test has do not match what widgets and corresponding
a11y implementations would be relevant for that dialog
today.
The test can be seen failing by enabling it locally
like this
--- a/toolkit/qa/unoapi/toolkit_1.sce
+++ b/toolkit/qa/unoapi/toolkit_1.sce
@@ -22,7 +22,7 @@
-o toolkit.AccessibleDropDownComboBox
#i86110 -o toolkit.AccessibleEdit
#i86110 -o toolkit.AccessibleList
-#i86110 -o toolkit.AccessibleListBox
+-o toolkit.AccessibleListBox
#i86110 -o toolkit.AccessibleListItem
-o toolkit.AccessibleMenu
-o toolkit.AccessibleMenuBar
and then running `make JunitTest_toolkit_unoapi_1`.
Just drop the test altogether.
If there should be a relevant test again in the future,
writing a new (C++, see [1]) one from scratch seems more
promising than having to deal with this outdated and disabled
test.
Dropping it also prepares for more upcoming vcl a11y changes
that would break even more assumptions that the test makes.
[1] https://wiki.documentfoundation.org/Development/Accessibility_Unit_Tests
Change-Id: Idbd01f92c78cd78005b306114c53f9946fa4d35f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210348
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
vcl::WindowData is used to manage/store various state
information for windows. It can be (de)serialized to/from string.
So far, both the weld::Window API to get/set window state
as well as the SvtViewOptions API were based on the string
representation.
Switch those and various related places to using vcl::WindowData
instead to use a stronger/more specific type than just OUString
in various places across the code base.
Do the string (de)serialization where necessary, but otherwise
prefer to use vcl::WindowData directly.
Calling weld::Window::set_window_state with a WindowData
param that doesn't indicate that anything should be set
(i.e. whose mask is vcl::WindowDataMask::NONE) should
have no effect, so drop extra checks that were previously
checking whether the string representation was empty
and skipping the call to weld::Window::set_window_state in
that case.
No change in user-observable behavior intended or
seen in a quick test.
Change-Id: I5bc4caeb49d0ab2bbc4fa597a5ef19d86d3aac2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208125
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch the weld::Entry and weld::TextView handlers
that are called when the text changes due to user
interaction to pass a weld::TextWidget& param
instead of a weld::Entry& and weld::TextView&
one respectively.
Adjust related methods across the code base accordingly.
This unifies the behavior for both of these
weld::TextWidget subclasses and prepares for
deduplicating the logic and moving it to the
common base class in an upcoming commit.
That will also ensure they stay in sync.
(Change also motivated by the fact that their behavior was
differing before
Change-Id: I03d2a13cd84d53d806eb9e363f49c4b6be28d938
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Jul 9 13:08:58 2026 +0200
tdf#130857 weld: Don't signal about programmatic TextView text change
.)
Change-Id: I5572fc88caf577fae9a23a39f1ec4f2179935a99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207936
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
This makes it easier to keep an overview and reduces
what needs to be recompiled if the class changes in
the future.
Change-Id: Ie8d0aad9bca3e990f78d4ffc006a04b0a8086fd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205935
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Adjust includes in files that were implicitly depending
on transitive includes that are no longer present because
the more specific include/weld/Container.hxx is included
further down now instead of include/weld/weld.hxx.
Change-Id: I04e6bb72ce446b746dfdf88b45c7df9d0ccda473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205899
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: Ide86f35543468a88288a068cc9f89eaf381ac52f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205763
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I2eb564b2483b052f01d4af55fd4feb00b5ed6031
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205472
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
* Checkbox label and position as well as button width and margins
at the UI changed
* Consistent access to the variable via a new class including
the consistent storage of the query flag
* Additional buttons added to have homogeneous Yes/No as well as
non-homogeneous long names, eg. for file formats
Change-Id: Icfbd923b298e1192a1474519543986142167f6c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203572
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Toggle on/off for visibility, locked state, and sensitivity,
the latter behind ExperimentalMode as it works only to suppress
the toolbar but not to make it always visible
Change-Id: Ia65a27045472d42fc013970bf9de64320f2dbcdc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195836
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Move the so far framework-internal headers layoutmanager.hxx
and the uielement.hxx one that it includes to the
top-level include/ directory and mark LayoutManager as
FWK_DLLPUBLIC.
This is to prepare for a new version of Heiko's [1]
that doesn't require UNO API changes, but can use
the LayoutManager class directly.
[1] https://gerrit.libreoffice.org/c/core/+/195836/9
Change-Id: I7439274c29814ef23c6fde11770e1519e54bc0b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197338
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
This reverts commit 086fa727ca.
Reason for revert: Breaks possibility to lock a toolbar (is forgotten after restart)
This solution will be succeeded by 1b1577eef6a30f2643d373c450576d5244ab6af1
Change-Id: Ida73a80ecfa2a833caf1db7d625ff90dbf259c2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196780
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Move the class out of weld.hxx into its own header, in
order to make it easier to keep an overview and to avoid
having to recompile ~all UI code when the class is
modified.
Change-Id: I5b23b02151c75bb49831a2bbf8d515eb0b54415e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199068
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
this was skipped in previous runs, since it contains some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: If1e3e3c7c0fc14ed6e8b51174a0e7f1220fdbc8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197496
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
these were skipped in previous runs, since they contain some code behind #if
After inspecting these, it seems like the removals should not cause trouble.
Change-Id: I867ffc53254057e4bae43690214a2ab7ce0caa8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197493
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Tested-by: Jenkins
ApurvR20