we already declare the same thing in various places,
and I intend to be using this some more, so it makes
sense to only declare it in one place
Change-Id: Ifea6b589e992dd9f6cd8f2301f837e71397481c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176046
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I have a case where LOK convert-to with ODT->PDF and
SignCertificateCaPem/SignCertificateCertPem/SignCertificateKeyPem set
creates a corrupted PDF signature, while more or less the same on the
desktop works.
The PDF signature is a hex dump, and once converted to binary, one can
analyze the content using 'openssl asn1parse -inform der -in ... -i'.
Still, the LOK and the desktop case differs, because this script
generates random certificates and then the binary output in the two
cases differs, so hard to see the actual difference.
Fix the problem by still generating .p12 output (needed for the desktop
case) in the no-password case, so a single run can emit ca/cert/key PEM
files and a .p12 archive, so exactly the same input can be used for
desktop and LOK signing.
It turns out the actual problem I looked at was some setup problem,
because now that the same input can be used in the two cases, the LOK
signing during PDF export works fine.
Change-Id: Ifc5ff73cd6fbbc057af536c84e4367ce1d489931
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176081
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Before this, the non-ASCII Windows-1252 characters get exported to RTF
without Unicode markup, regardless of the font-defined charset; and on
import to Writer (and other compliant RTF readers), this 8-bit markup
was interpreted using the font data, producing different characters.
Change-Id: I2032930b6585287fde3eb3b5e6abed0298d29330
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176048
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Using a local build having both commits
9f53d40fd1 "Related: tdf#163730 Avoid
deadlock", 2024-11-02, and 3015db08c9
"Related: tdf#163730 Avoid potential deadlock", 2024-11-03, I got
another deadlock (unfortunately, I didn't copy call stacks), where
main thread, holding soler mutex, called CWinClipboard::setContents,
and that tried to lock solar mutex in CMtaOleClipboard::run thread,
which released the m_foreignContent data.
This change releases m_foreignContent in a separate thread, which
has no dependencies, and so its wait wouldn't block other threads.
Change-Id: If4c486e6f3ba9201c4c9c6991992e38929ab3b81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176047
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
This includes writing ORG.OPENOFFICE.EASTERSUNDAY for ODF 1.3 and
ODF 1.2.
Change-Id: Ifa19021060f0d0223234c1ca1109300908e2dda1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175736
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Since
commit 2e25618fe7
Author: Mike Kaganski <mike.kaganski@collabora.com>
Date: Mon Jul 8 12:12:49 2024 +0500
Make convert*Angle strict
V1001 The 'fAngle' variable is assigned but is not used by the end of the function.
V1001 The 'fAngle' variable is assigned but is not used by the end of the function.
Change-Id: Ie0c9059e18518cae46854715fa7d39cc9c942549
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175933
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Attempt to avoid the cost of GetCondResult when dealing with large runs
of identical cells
This restructures my caching code to increase the chance of hitting the
cache.
Change-Id: Ic83ff467be05fd645c80276708adb627c6b297d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176007
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 2ebb1205485cdc0bdd868ee0abe83e6a288b50da)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175997
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
name in Function list box in the Customize dialog Keyboard tab
In SfxAcceleratorConfigPage Reset, RadioHdl is called just before
m_xGroupLBox->SelectMacro. In RadioHdl an idle timer is started whos
handler gets fired after m_xGroupLBox->SelectMacro is called in
Reset. This makes the selection made in the functions list box by
m_xGroupLBox->SelectMacro in Reset get bonked by the call to
m_xGroupLBox->GroupSelected in SelectHdl called from the idle timer
handler. m_xGroupLBox->GroupSelected always selects the first
function in the function list box. This patch fixes this selection
bonk by calling SelectHdl directly from RadioHdl instead of calling
SelectHdl from an idle timer handler.
Change-Id: I15d26d4611948d61e0a258e9a350d8c952b2b211
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176038
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
For VLOOKUP nSearchMode was 0. So static_cast<SearchMode>(nSearchMode)
casts to a value which does not exist in SearchMode enum. That gives an
"undefined behavior". Better to use the valid default forward search. (1)
Change-Id: I1757b43073e13638704b96c4a9d036cb9a21e470
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176043
Reviewed-by: Balazs Varga <balazs.varga.extern@allotropia.de>
Tested-by: Jenkins
* Update translations from branch 'master'
to 50f69fbf1374ebbe4f284d37c8280e972a2abd88
- update translations for master
and force-fix errors using pocheck
Change-Id: I82c3048355e1bd1c6ddac5f8991019276b7a3f60
The fix in commit 2fe53b2e43 still
works on macOS with a forward declaration of the VCLXMenu class.
Change-Id: I1080466d1783464c886111e9b47d445fb16f0d3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176045
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
now that the other end can use html
Change-Id: Idb7959b041ebbbd9284007594473019cf603981f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175166
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 9ed5dd5d1b48b9a17967d85c0fad4994c40caafa)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175998
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
...where clang::CXXRecordDecl::forallBases is documented as: "This routine
returns false if the class has non-computable base classes." So, presumably
since
<bf099f4682>
"[llvm][ADT] Structured bindings for move-only types in `StringMap` (#114676)"
changed
> -template <std::size_t I, typename ValueTy>
> -struct tuple_element<I, llvm::StringMapEntry<ValueTy>>
> - : std::conditional<I == 0, llvm::StringRef, ValueTy> {};
> +template <std::size_t Index, typename ValueTy>
> +struct std::tuple_element<Index, llvm::StringMapEntry<ValueTy>>
> + : std::tuple_element<Index, std::pair<llvm::StringRef, ValueTy>> {};
in LLVM's llvm/include/llvm/ADT/StringMapEntry.h, our !forallBases check here
started to trivially always be true for that struct tuple_element
specialization, so the isDerivedFrom check in
CheckFileVisitor::VisitCXXRecordDecl in
compilerplugins/clang/sharedvisitor/analyzer.cxx started to erroneously be true
for that struct, so it started to generate
compilerplugins/clang/sharedvisitor/*.plugininfo files with bogus extra
> InfoVersion:1
> ClassName:tuple_element
> InfoEnd
content, which in turn caused the generated
compilerplugins/clang/sharedvisitor/sharedvisitor.cxx to contain lots of
> #include "tuple_element.cxx"
and other nonsense, which caused the build to break with
> [CXX] compilerplugins/clang/sharedvisitor/sharedvisitor.cxx
> lo/core/compilerplugins/clang/sharedvisitor/sharedvisitor.cxx:20:10: fatal error: 'tuple_element.cxx' file not found
> 20 | #include "tuple_element.cxx"
> | ^~~~~~~~~~~~~~~~~~~
etc.
(And now spelling out the implementation of forAnyBase here also reveals that
BaseCheckSubclass will never be called with a null BaseDefinition, so the code
handling that has been removed.)
Change-Id: I8a6e42260eae86852ec37a80d058777653fac394
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176042
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...after c8cba8ae30 "move CryptTools from oox to
comphelper so we can reuse it"
Change-Id: Id899c9fac9f18833afd64f18d81a7ad50916872e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176041
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
When an optimized build of this branch is compiled on Silicon Mac,
a dynamic_cast from com.sun.star.awt.XPopupMenu to VCLXPopupMenu
will fail.
The pointer being casted has not been deleted and is an undeleted
instance yet dynamic_cast fails. However, a dynamic_cast to
VCLXPopupMenu's superclass VCLXMenu succeeds so cast to that class
instead.
Change-Id: Ie9ab79df109eece46351545a71325d1e37bde94d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175992
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
For "GtkBox" and "GtkGrid" objects in .ui files,
don't just create the corresponding QLayout objects,
but create an extra QWidget object and set the
layout for that widget, i.e. use that QWidget as
the parent.
While this generally wouldn't be needed to properly
layout/handle things in Qt, having an associated
QWidget for the "GtkBox" and "GtkGrid" children
is needed in order to be able to create a
corresponding weld::Container (QtInstanceContainer)
for these, which derives from weld::Widget.
QLayout itself doesn't have the methods required to
implement weld::Widget, e.g. can't be hidden or shown.
Therefore, create a QWidget for these in addition,
except for special cases like the top-level layout
in a dialog or the dialog's button box.
For QGroupBox (created for "GtkFrame" objects),
this now means that the direct child is no more
necessarily a layout. Just setting a QWidget
as a child wouldn't suffice for proper layouting.
Therefore, explicitly create a layout for parent
widgets that don't have a layout set yet.
Adjust QtBuilder::applyPackingProperties
accordingly as well. Now, there's no more
use case to call QtBuilder::applyGridPackingProperties
with a QLayout for the current child. Get the
corresponding QWidget parent (if there is one)
before calling the method instead, and switch the
param from QObject* to QWidget* to simplify the
method.
Having an extra widget might have the side-effect
that extra spacing/margins might be used. If that
turns out to be a problem, these can presumably
explicitly be reduced (e.g. set to 0 for the relevant
objects) as needed later.
At least the 19 dialogs currently listed as supported in
QtInstanceBuilder::IsUIFileSupported still look OK to
me in a quick test with this commit in place.
Actually making use of the newly added widgets
to implement more of the QtInstanceContainer logic
will be done in separate commits.
Change-Id: I3d3600ddfc7883239177aafed57629c107cbdf5d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176033
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add .ui file for the password that can be triggered via
"File" -> "Properties" -> "Security" -> "Protect..." in Writer.
This means that native Qt widgets are used for that dialog
now when LO gets started with environment variable
SAL_VCL_QT_USE_WELDED_WIDGETS=1 set.
Change-Id: I106444178cd89b0f37b97bb528a144652fbb2567
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176019
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
For weld::EntryMessageType::Warning and
weld::EntryMessageType::Error, set a warning/error
icon from the icon theme at the end of the entry using
QLineEdit::addAction.
The GTK implementation (GtkInstanceEntry::set_message_type)
also does this. That one also sets a background color, which
the Qt implementation doesn't do for now.
This method is used e.g. by the "File" -> "Properties"
-> "Security" -> "Protect..." dialog in Writer, which
will be declared as supported in an upcoming commit.
Change-Id: I96b81e28faf82f17e33195cfa981c82522f59b98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176018
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Except for the simple message dialogs created in
QtInstance::CreateMessageDialog, disable the use
of native Qt dialogs by default for now, and only
use those if the user explicitly opts in to use
them by setting the SAL_VCL_QT_USE_WELDED_WIDGETS
environment variable.
While those dialogs declared as supported in
QtInstanceBuilder::IsUIFileSupported are meant to be
fully functional, they are only a small subset
of all LO dialogs and not all properties for
widgets are evaluated by QtBuilder at this point in
time (e.g. not all spacing, margins, text formatting
properties,...).
Therefore, default to VclBuilder again for now in order
to have a more consistent visual appearance for dialogs
with the Qt-based VCL plugins.
This can be reconsidered in the future, but at least for
25.2, sticking to VclBuilder by default seems reasonable
to me.
Change-Id: I7b275d3d3759093a6680327faeb3b86d7c623cea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176013
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Otherwise, "Use level from source chapter" does not work for Graphics and Frames in user-defined indices.
Change-Id: I148a097276cf8a60d69a208266ceb9def0444654
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175783
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
The expression can't be negative. It's a Pythagorean sum.
Change-Id: Ic07783c5291da71de6701a139227def2f1c4f77b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175989
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
V1037 Two or more case-branches perform the same actions. Check lines: 609, 637
Change-Id: I4376e86a5484886025152a9a407b23b3d05c3911
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175355
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
V1037 Two or more case-branches perform the same actions. Check lines: 734, 739
V1037 Two or more case-branches perform the same actions. Check lines: 1031, 1054
Change-Id: I835ac504eadcbdd44b2ee507f40e6f40ff5e416d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175318
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Tested-by: Jenkins
V1037 Two or more case-branches perform the same actions. Check lines: 778, 793
Change-Id: I2437bbac1bc952720d4ea3c43107c9d5e1ef1655
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175308
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
V1037 Two or more case-branches perform the same actions. Check lines: 764, 767
Change-Id: Ia8da107d28249132b92e7cf533505b09c0037188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175310
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
V1037 Two or more case-branches perform the same actions. Check lines: 574, 577
V1037 Two or more case-branches perform the same actions. Check lines: 738, 752, 759
V1037 Two or more case-branches perform the same actions. Check lines: 1949, 1953
Change-Id: I2a6b6cc16ff58d432e5a7b14a6a1d7fa4f1a15b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175313
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
V1037 Two or more case-branches perform the same actions. Check lines: 767, 777
Change-Id: Ie9a6d6376f5037ee075c95e62c2c7970b720e9a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175309
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Moving more PDF encryption implementation into common encryption
files. This will make it easier to add new encryption later on as
the code will be in one place.
Change-Id: Id40c2f876a2e92bb8db27024a0e251befc5059e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176030
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Also rename to EncryptionHashTransporter.
Change-Id: I20f984af4428e1182c77dbce4343d69c106063a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176029
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
