Instead of having definitions of the
SfxCharmapContainer methods interspersed with those
of the SfxCharmapCtrl one in the same source file, move
them to an own source file.
Also move the class definition to an own header for
consistency.
This makes it a bit easier to keep an overview.
Change-Id: Ibf05b564e5936bee2bfda612b43fe0ecac26ddc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195345
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Similar to how
commit 2ef9880f97
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Sun Jul 30 01:59:31 2023 +0200
tdf#156376 qt: Open help for focused native menu entry on F1
did for e.g. for the main window menu, also implement
the logic to open the help for the current weld::Menu
entry when F1 is pressed.
In QtInstanceMenu::set_item_help_id, set the corresponding
property for the menu entry's QAction.
Keep track of the current/last active menu item
in QtInstanceMenu::m_pCurrentAction, and open
the help for that action's help ID if it's non-empty.
This will be used e.g. for the following scenario once
support for that dialog will be declared:
* start Writer
* "File" -> "Templates" -> "Manage Templates"
* enable the "List View" by clicking on the corresponding
button
* select an entry and right-click on it to open the context
menu
* navigate between entries and press F1 while an entry is
h highlighted to open the help page specific to the currently
highlighted entry
(More is missing to be able to eventually declare support for
that dialog, but this makes opening the corresponding help page
work in a corresponding local WIP branch.)
Change-Id: I906a779c33bdf1812ad5fd1590fe45096d53fe70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195343
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Extract the logic from QtInstanceWidget::get_help_id
to a new static helper method.
This will be reused in QtInstanceMenu
in an upcoming commit.
Change-Id: Ifc6ac06232db1fd4e865af22b556eff0229cd55d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195341
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Call the base class method weld::TreeView::signal_popup_menu
when a QContextMenuEvent is received in QtInstanceTreeView's
underlying QTreeView.
This will be used e.g. for the following scenario once
support for that dialog will be declared:
* start Writer
* "File" -> "Templates" -> "Manage Templates"
* enable the "List View" by clicking on the corresponding
button
* select an entry and right-click on it to open the context
menu
(More is missing to be able to declare support for the dialog,
but this makes showing the context menu work in a corresponding
WIP branch.)
Change-Id: Ib6e66e12669462da839063a7642e02ba125818c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195338
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Let weld::TreeView::signal_popup_menu return the return
value of the handler it calls, and call the method
instead of the handler directly in the GTK and
vcl subclasses.
Make weld::TreeView::m_aPopupMenuHdl private, as
it's now only directly used from within the class
itself.
Change-Id: I4f5c693596e76bbdfbb172468e584174fe0df6c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195337
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Following
Change-Id: I77b7b12d0087eac8afeb88d4847a95ed268bfc5f
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Tue Dec 9 18:43:39 2025 +0100
sw: Use weld::IconView in ThemePanel
, also set accessible names for the items in the
sidebar, which e.g. makes the Orca screen reader
announce those when they receive focus with the
gtk3 or qt6 VCL plugin.
(They also had no accessible names set before the
above-mentioned commit, so only "Item 1", "Item 2"
etc. were announced.)
See the above-mentioned commit for more details
on how to trigger the relevant code path.
Change-Id: I3fc075a5d9f14de3badc3b3ba99e1ce3fa5cbabb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195325
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Replace the use of a custom ValueSet subclass
ThemeColorValueSet to display the themes to choose
with a more standard weld::IconView.
Besides reducing custom logic, it also ensures
that theming/styling adheres better to the rest
of the application, e.g. the way that the currently
selected theme in the sidebar is highlighted.
In this case, it also makes sure that actually
all themes are shown: Previously, only 6 of them
instead of all 7 were displayed, due to hard-coding
the number of rows and columns in the ThemePanel ctor
mxValueSetColors->SetColCount(2);
mxValueSetColors->SetLineCount(3);
Now, all 7 themes are shown and can be selected.
The newly introduced helper method ThemePanel::CreateImage
mostly takes over the existing logic from the (now dropped)
ThemeColorValueSet::UserDraw.
Drop the now no longer used ThemeColorValueSet.
An upcoming commit will also set accessible
names for the themes, which wasn't previously
done either.
The theme panel can be reached as follows:
* start Writer
* in "Tools" -> "Options" -> "Advanced", enable
"Enable experimental features (may be unstable)",
press "OK" button, restart LO to apply those changes
* open the "Design" sidebar panel in Writer
The list of theme colors in the "Themes" section
is the one that was switched to weld::IconView
by this commit.
The "Format" -> "Themes" dialog shows the same
set of color themes and can also be used while testing
that a change to the color theme in the sidebar
was actually applied as expected.
Change-Id: I77b7b12d0087eac8afeb88d4847a95ed268bfc5f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195324
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
* Update translations from branch 'master'
to 27eb5b5f79946c6faab920a972fe8903f773be0a
- update translations for master/26-2
and force-fix errors using pocheck
Change-Id: I7dc347446a939379271d919ebf3657be6ea9a497
Added in
commit 2d69acfde5
Author: Heiko Tietze <tietze.heiko@gmail.com>
Date: Fri Jan 8 15:10:42 2021 +0100
Resolves tdf#139343 and tdf#139335 - Community/Enterprise flavor
it only adds "LibreOffice Community" to the version string
in the about dialog, which is not really useful at this point,
since final releases don't use it either
Change-Id: Ifdd7a91cdd18a016c104aea871fb7dc9c42fa97a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195106
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Revert the problematic part from e5f0dad2b38d2a3902a9cd6b9d434abc206590a4
"tdf#168452: support unicode-bidi in svg"
until a better solution is found
Change-Id: If21b0c38b5fd8bdade0538e4960353d156e17e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195307
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In a pptx file with a slide master that has multiple slide layouts, the
footer would loose properties when saved in LO and opened in MSO.
This is due to the master de-duplicating logic that in trying to emulate
pptx's natural way of dealing with master and layout slide it treats
multiple Impress masters as equivalent. This is needed for most export
functions, but when exporting an element from an Impress slide that
references an Impress master (like a footer), we need to differentiate
exactly which one of the equivalent masters it comes from to make the
indices match.
Change-Id: I815c3db54256d934b69108c7268f6d7642c33cbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194190
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 0f21756af8e74b0dd3f25fe4234feb067430838b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195225
Tested-by: Jenkins
Reviewed-by: Jaume Pujantell <jaume.pujantell@collabora.com>
That
> // the exception base functions want to have an "args" tuple,
> // which contains the message
code is there ever since e80bdbafeb "initial
checkin for the pyuno-0.9.2 release" for reasons that are not clear to me, but
at least in the "TODO" scenarios from 3320b5fe2e
"Add exhaustive testing of PyUNO type mapping based on embindtest" and
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest" (which are hereby fixed), that
PyObject_SetAttrString would cause a Python exception, cf.
> info:pyuno.runtime:1489432:1489432:pyuno/source/module/pyuno_runtime.cxx:533: setting exception args raised Python exception <class 'AttributeError'>: AttributeError('args')
so at least catch that. (And maybe that code is obsolete anyway it would make
even more sense to drop it altogether.)
Change-Id: Ic651d106f34e0b316cba59ae66d2402b8f86b0f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195340
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
commit 676892af95 was my first stab.
This second effort aims to provide the expected behavior of not
changing the last used palette when it does not have a color match of
the 'Active' color. Additionally this patch handles when the
'Custom', 'Theme colors', or 'Document colors' palette is the last
used palette.
Change-Id: Ibce078778d8cad483448837dbb6364acbf668a40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195265
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
Tested-by: Jenkins
(Stumbled over this when while preparing
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest" I accidentally forgot the
> from org.libreoffice.embindtest import Exception
in pyuno/qa/pytests/embindtest.py and thus PythonTest_pyuno_pytests_embindtest
would SIGABRT with
> sal/rtl/strtmpl.hxx:122: auto rtl::str::Copy(sal_Unicode *, const char *, sal_Int32)::(anonymous class)::operator()(char) const: Assertion `rtl::isAscii(static_cast<unsigned char>(c))' failed.
from pyuno::lcl_ExceptionMessage (with reprString being "('error', None,
-123456, 100.5, 'hä')") while trying to report
> uno.com.sun.star.uno.RuntimeException: Couldn't convert ('error', None, -123456, 100.5, 'hä') to a UNO type; caught exception: <class 'AttributeError'>: 'Exception' object has no attribute 'getTypes', traceback follows
.)
Change-Id: I4581061dbfa190266fef98dc670a058d6c98eaaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195304
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
Using Excel 2024, I saved the control
with a black, a blue, and a transparent background.
The only differences in the files
were in the activeX/activeX1.bin file,
and in the media/image1.emf file.
Currently we can't use LO to save different colours anyway,
so if we are only going to support one choice,
then the best choice is transparent - which is
the default of a new control.
make CppunitTest_sc_subsequent_export_test4 \
CPPUNIT_TEST_NAME=testCheckboxFormControlXlsxExport
Change-Id: I6d4a24fa43d4c12ce412d5bf3abb02e7347d3efc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195263
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
svx/source/svdraw/svdedtv1.cxx:1011:56: runtime error: downcast of address 0x7bd2deeea930 which does not point to an object of type 'const SfxUInt16Item'
0x7bd2deeea930: note: object is of type 'XFillTransparenceItem'
00 00 00 00 90 ee bd 84 a2 7b 00 00 00 00 00 00 fb 03 be be 17 02 00 00 89 be 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'XFillTransparenceItem'
after
commit 953219b811
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Wed Dec 3 21:34:19 2025 +0200
make XFillTransparenceItem extend SfxPoolItem
Change-Id: Id29305cf0a7b7431207aaa7f8ede639f035a630e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195276
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...by implementing all the getAny... variants that were left out of
5f05929fd1498e418618d7570192877055de2c80 "Add exhaustive testing of PyUNO type
mapping based on embindtest".
Which revealed that the code in Adapter::invoke (in
pyuno/source/module/pyuno_adapter.cxx) was apparently broken, and would cause
the C++ call in doExecuteTest (in unotest/source/embindtest/embindtest.cxx) of
the Python
> def getAnyByte(self):
> return uno.Any('byte', -12)
(in pyuno/qa/pytests/embindtest.py) to fail with a nonsensical
> uno.com.sun.star.uno.RuntimeException: uno.Any instance not accepted during method call, use uno.invoke instead at pyuno/source/module/pyuno_runtime.cxx:785 at stoc/source/invocation_adapterfactory/iafactory.cxx:203
In addition, there's two new places marked with TODO comments:
For one, executing C++
> bool const ok = test->isAnyException(val);
would cause an odd
> python.bin: Objects/typeobject.c:4745: PyObject *_PyType_Lookup(PyTypeObject *, PyObject *): Assertion `!PyErr_Occurred()' failed.
failure that needs further investigation.
And for another, executing Python
> return value == self
would always return false. It appears that PyUNO_cmp (in
pyuno/source/module/pyuno.cxx isn't yet prepared to be called with `that` being
a native Python UNO-implemenation object (`class Test(unohelper.Base, XTest)`)
instead of a proxy for a binary/C++ UNO object.
Change-Id: I0289e1f5ee6dab53b589af783c0c53302989394c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195287
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...as vertTitleAndTxOverChart, if ODP layout was
AUTOLAYOUT_NOTES, causing corruption.
PPTX export code directly matched LO's AutoLayout IDs to
PPTX layout types (OOXML spec: 19.7.15 ST_SlideLayoutType
(Slide Layout Type)) without conversion, as some don't have
direct match, and need to be matched to blank layouts. This
could result in PPTXes that can't be opened in PowerPoint.
It could also result in PPTXes with wrong layout types when
using LO's own vertical layouts. The files could still be
opened in PP in this case.
In addition, import code imported vertical PPTX layouts
with wrong IDs, matching them to notes and handout autolayouts.
Part of the mentioned behavior happened since
bff76421e2.
Change-Id: Iba7a50795979c22bc566aa2cd6ea4d82f7f9477e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195049
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Aron Budea <aron.budea@collabora.com>
/svx/source/sidebar/area/AreaPropertyPanelBase.cxx:820:42: runtime error: downcast of address 0x5030003750d0 which does not point to an object of type 'const SfxUInt16Item'
0x5030003750d0: note: object is of type 'XFillTransparenceItem'
00 00 00 00 d0 74 21 ac 12 7f 00 00 00 00 00 00 fb 03 be be 15 00 00 00 89 be 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'XFillTransparenceItem'
#0 0x7f12b02722cf in svx::sidebar::AreaPropertyPanel
after
commit 953219b811
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Wed Dec 3 21:34:19 2025 +0200
make XFillTransparenceItem extend SfxPoolItem
Change-Id: Iaee48c5f5522cab8ec48cffd621cc866151429af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195235
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Christian Lohmaier