Add a new QtFrame::handleResizeEvent and move the
logic from QtWidget::resizeEvent to the new method
and call the new method from QtWidget::resizeEvent.
This decouples QtFrame and (its friend class) QtWidget
a bit more, and also prevents direct access to the
(currently public) SalFrame::maGeometry member from
QtWidget.
Change-Id: I8969687c64b87677836b436b7815298a8e8d5cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173952
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add a new QtFrame::handleMoveEvent and move the
logic previously duplicated in both,
QtMainWindow::moveEvent and QtWidget::moveEvent
there, then call the new method from these two.
this also prevents direct access to the
(currently public) SalFrame::maGeometry
member from QtWidget and lets the subclass
do it instead.
Change-Id: I468802f204d3ac5869d833526286ca8ab349697b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173951
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
after
commit 9153a36b59
Author: Chris Sherlock <chris.sherlock79@gmail.com>
Date: Fri Mar 28 23:30:02 2014 +1100
fdo#74702 Refactor OutputDevice::DrawTransparent()
where it looks like a copy/paste error resulted in the metafile
and mpAlphaVDev being restored too early.
Change-Id: Ib2989927166bc2da7c8da6274f295a73218386fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173935
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
after
commit 3c82f49fce
Author: Armin Le Grand (allotropia)
<armin.le.grand.extern@allotropia.de>
Date: Mon Sep 23 17:57:00 2024 +0200
Adapting basegfx.py due to blocking in some situations
Change-Id: Ie266c7b5aeb5dccaae03c26b7cd73cd65841748c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173949
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Now that
Change-Id: If6e03bfa48b9052016539a25aadf40b599095918
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 25 12:10:12 2024 +0200
tdf#130857 qt weld: Implement QtBuilder::set_response
implemented handling for button response codes,
let QtInstanceBuilder create the "Save Document?"
dialog that shows when closing LibreOffice while
an unsaved modified document is open.
This means that a native QMessageBox is now used for
that dialog as well, unless env variable
SAL_VCL_QT_NO_WELDED_WIDGETS is set.
Change-Id: Ifb6c6f181d95d88138ed49f382b9eaad4d3ad944
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173932
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Implement QtBuilder::set_response to set the
given response code for a button:
Set the `PROPERTY_VCL_RESPONSE_CODE` property
on the QPushButton.
`QtInstanceMessageDialog` makes use of that property
to return the corresponding response code of the
pressed button.
(Make `PROPERTY_VCL_RESPONSE_CODE` a static
member of `QtInstanceMessageDialog` to make
it available outside of the class as well.)
This works for buttons in message dialogs.
An implementation for other dialogs still needs
to be added when adding suppor for these to `QtBuilder`
and extending `QtInstanceDialog`/`QtInstanceButton`
accordingly.
Change-Id: If6e03bfa48b9052016539a25aadf40b599095918
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173931
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move mapping the (GTK) response code set in the .ui file
to the VCL equivalent from VclBuilder::set_response
to BuilderBase::handleActionWidget.
As VCL response codes are used by all implementations, this
is not specific to the vcl::Window implementation and
also allows an upcoming QtBuilder::set_response_code
implementation to use the passed value as is.
Change-Id: I5b6d262a657932038c423c0c2cdcf1fd32c8b6be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173930
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
... instead of reimplementing the logic in
VclBuilder::set_response.
Change-Id: I634d918a356caddc79419b94dda7bd0657fa8c20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173929
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This prepares for reusing the method elsewhere in
`VclBuilder`.
Only the `SAL_WARN_IF` (a no-op in release builds without
`--enable-sal-log`) previously needed a `OUString`.
Call `OUStringToOString` for that one explicitly, which
is what previously happened implicitly by
template< typename charT, typename traits >
inline std::basic_ostream<charT, traits> & operator <<(
std::basic_ostream<charT, traits> & stream, OUString const & rString)
defined in include/rtl/ustring.hxx.
Change-Id: I57ebac8c2189afeca33bfa483b8d5d5c7866d904
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173928
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Convert the single caller of the other variant to use
the same as all other places, and drop the now unused
method.
Change-Id: Icde971b50f39cb8c8f32d1a6ddf4d0cc84f90440
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173927
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This implements an initial QtBuilder, which is used by
QtInstanceBuilder to create weld::Widget instances
using native Qt widgets.
This tries to be close to the VCL implementation (VclBuilder).
The selected approach is based on Caolán's suggestion in [1] to
rework VclBuilder to have overridable methods for widgets creation.
This way, we can have common code for the UI parser but the
function for widget creation is different.
Qt equivalents for Gtk's widget classes in the .ui files:
* GtkMessageDialog -> QMessageBox
* GtkBox -> QLayout (can be QVBoxLayout/QHBoxLayout based on
property in .ui file)
* GtkButtonBox -> QDialogButtonBox
* GtkButton -> QPushButton
As QMessageBox already comes with a layout and
a QDialogButtonBox, don't create new ones, but
return the existing ones in QtBuilder::makeObject.
This commit implements initial support for the
above-mentioned widget types and adds the first
message dialog to the list of supported .ui files
in QtInstanceBuilder::IsUIFileSupported,
so a native QMessageBox is used for it now, unless
environment variable SAL_VCL_QT_NO_WELDED_WIDGETS
is set when starting LibreOffice.
The dialog ("modules/swriter/ui/inforeadonlydialog.ui")
gets shown when taking the following steps:
* start Writer
* type "hello world"
* select text
* "Insert" -> "Section"
* tick the "Protect" checkbox in the "Write Protection" section
* close dialog via "Insert" button
* try to type in the protected section
The dialog can be dismissed using the default "OK" button.
(Handling for response codes for buttons is not implemented
yet, which will be needed when welding dialogs that have multiple
buttons resulting in different behavior depending on what button
gets clicked.)
This change was originally submitted as a WIP change as part of
Omkar Acharekar's Outreachy project "Implement Qt/KDE Frameworks
theming using native Qt widgets" (see [2]), then further refined
by Michael Weghorn.
[1] https://lists.freedesktop.org/archives/libreoffice/2023-December/091288.html
[2] https://lists.freedesktop.org/archives/libreoffice/2023-December/091281.html
Co-authored-by: Michael Weghorn <m.weghorn@posteo.de>
Change-Id: I6dd010a2138c245dc1e6d83dd08123898e9d9048
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161831
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Extract logic to start parsing/processing the VclBuilder's
.ui file from the VclBuilder ctor to a new helper method in
the base class, WidgetBuilder::processUIFile.
This will allow to reuse it in the upcoming QtBuilder.
Change-Id: Ia7d31563e5aeef0786b0db34abb1a32a3a479947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173902
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Pass the UI file root down to `BuilderBase`, and add
a new getter `BuilderBase::getUIFileUrl` to get the
URL composed of the UI dir and the UI file passed to
the ctor.
This is in preparation of moving the `XmlReader`
creation out of the `VclBuilder` ctor, so the code
can be reused by the upcoming `QtBuilder`.
Change the UI directory param from `const OUString&` to
`std::u16_string_view` as suggested by the clang plugin.
Change-Id: I3f7719e30e55bae3c774da704e642e4227165a76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173827
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move `VclBuilder::handleObject` to the template base class
`WidgetBuilder` introduced in previous commit
Change-Id: I2d81cc6dd54d796b549357a4444b95627661c623
Author: OmkarAcharekar <omkaracharekar12@gmail.com>
Date: Fri Sep 20 13:33:01 2024 +0200
tdf#130857 refactor VclBuilder: Extract template base class
Add new virtual methods to that base class to override in the
subclasses. These are currently the ones that `VclBuilder`
already implements for `vcl::Window`.
More refactoring - in particular for those methods that currently
still do XML parsing themselves is planned for the future
once the relevant functionality will be implemented in
other subclasses. For now, those methods that do XML parsing
themseslves trigger an assert in the base class implementation
and remain unchanged in the `VclBuilder` implementation.
One aspect to be aware of is that `WidgetPtr` should explicitly
be initialized to `nullptr` if not assigned a different value:
While `VclPtr` that gets used for `VclBuilder` has a default ctor
that takes care of proper initialization, that's not the case for
the upcoming `QtBuilder` [1] that just uses `QObject*` for `WidgetPtr`.
[1] https://gerrit.libreoffice.org/c/core/+/161831
Change-Id: I5c1b7201c82ca2c0c2d7389642aee407ebea16ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173737
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Refactor `VclBuilder` by extracting the `handleChild` method
and moving it into a new template base class `WidgetBuilder`,
so both `VclBuilder` and an upcoming `QtBuilder` (see [1])
can share the common logic to parse the .ui file and override
the virtual methods like `applyPackingProperties`,
`tweakInsertedChild` etc. to handle toolkit specific cases,
as mentioned as one potential approach in Caolán's email [2].
The new class has 2 template parameters `Widget` and `WidgetPtr`
to account for the fact that `VclBuilder` doesn't just use
`vcl::Window*`, but there's a specific class, `VclPtr`.
As the inline comments say, more refactoring will be needed
to abstract the current `VclBuilder` implementations
of various methods from the `vcl::Window` specifics and
make them reusable for other subclasses as well, but this
commit is a start. The idea is to allow for incrementally
refactoring aspects relevant for specific .ui files/features
rather than having to refactor everything and implement
support for all widget types at once, see also
commit 9b3a2996e7
Author: OmkarAcharekar <omkaracharekar12@gmail.com>
Date: Wed Sep 18 09:35:09 2024 +0200
tdf#130857 qt weld: Add QtInstanceBuilder skeleton
which adds an initially empty list of .ui files that
should be handled by the upcoming Qt-based implementation.
[1] https://gerrit.libreoffice.org/c/core/+/161831
[2] https://lists.freedesktop.org/archives/libreoffice/2023-December/091288.html
Co-authored-by: Michael Weghorn <m.weghorn@posteo.de>
Change-Id: I2d81cc6dd54d796b549357a4444b95627661c623
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163103
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
After this, the workaround introduced to
OpenDocument-v1.4+libreoffice-schema.rng in
afa4965e4d "schema: update to ODF 1.4 OS"
can be removed
Change-Id: Iecf31cec0bf187155a97e5b6ccf8173b6aba82fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173940
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
I can't reproduce the problem from tdf#136933 anymore (using kf5
and qt5), while it's reproducible using v.7.0 bibisect repo with
qt5. I conclude, that the problem got resolved in the meanwhile.
So it seems to make sense to just revert the problematic commit.
The incorrect line drawing still may need to be fixed eventually.
There seem to be no way to test SlideImpl::getCurrentSlideBitmap,
which eventually calls CanvasHelper::strokePolyPolygon. So this
change has no unit test, unfortunately.
Change-Id: I1d82b6f734a4f69d93c9d61732f55ef8158cfbe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173933
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Opening an odt file and saving it as docx would break the comment
threads into unconnected comments.
This also fixes a regression from commit
3bb2668f5e753e9fa6aa7eea74454bf11cdfc853 where creating a commet
thread with multiple children and saving to docx would break it
into separate threads.
Change-Id: I76a0ec49bd69b953d816b3b5d3cc6d14065d5846
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173681
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173872
Tested-by: Jenkins
Reviewed-by: Jaume Pujantell <jaume.pujantell@collabora.com>
Adds the option to convert a reply comment into a new top comment
while preserving the parent-child realtions of the other comments
in the thread.
Change-Id: I3cd5e5466fadc2226651d7c244b5139ec2d1f949
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173051
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173870
Reviewed-by: Jaume Pujantell <jaume.pujantell@collabora.com>
Tested-by: Jenkins
and
cid#1606991 Data race condition
cid#1607010 Data race condition
cid#1607323 Data race condition
cid#1607335 Data race condition
cid#1607635 Data race condition
cid#1608162 Data race condition
Change-Id: I65edcf08f92fb564d56d0e8954212533c1cbec91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173895
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
The hack was introduced in 7db1150b2c "fix macos
build with clang 16". (And for our --enable-pch for Clang being known-broken,
also see ffc1ab15ae "Work around some Clang PCH
consteval issue by disabling HAVE_CPP_CONSTEVAL".)
Change-Id: I5dcd7f96ba39bf4d0748940778699cb7d368f449
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173891
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Once the signing key is taken from the matching SfxViewShell (not yet
done), signing with a certificate specified via initializeForRendering()
failed with:
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/nss/x509certificate_nssimpl.cxx:330: X509Certificate_NssImpl::getPrivateKey() cannot find private key
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.cxx:812: Can't get the private key from the certificate.
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: keys.c:1347: xmlSecKeysMngrGetKey() '' '' 45 'details=NULL'
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:822: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL'
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:537: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' '
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:301: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxProcessSignatureNode' 1 ' '
The trouble was that we wanted to keep the private key in-memory,
presumably because initially the whole NSS database was in-memory for
the LOK case. This was changed in commit
87eec1b90b (NSS: create a temporary
database instead of in-memory, 2018-12-31), so there is no problem with
a not-in-memory private key anymore.
Note that the problematic codepath was only triggered when first the
certificate chooser was ran and only then we signed. So the testcase
also gets the cert flags before signing, otherwise the test would
succeed even without the fix.
Change-Id: I5086b205c91b630ddd343c0eb91bd9e63b3ea238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173892
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Added BColorModifierStack to SVG linear and radial
gradient direct support, was missing.
Change-Id: I1405ea0653180fa695b40082bf8b8520441d0620
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173871
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
I have stumbled over the GDB integration in vscode hanging
when there is a BP and *below* a declaration of e.g. a
basegfx::B2DPolygon. This seems to happen due to the
instance not yet being incarnated, but the variable view
already listing it and triggering methods in basegfx.py
to evalualte stuff.
It just hangs/loops, I guess it's fetching the PointCount
from a random mem ptr'ed Polygon, then tries to evaluate
something with the Points.
I do not really know about what to do here, but I figured
out that testing 'if self.exists()' where the instance
gets accessed (using gdb.parse_and_eval) helps.
Thus this solves the problem for me and - after stepping
over the incarnation of the object I can see it's true
content.
I hope someone who might have more knowledge about that
GDB and python stuff can have a look and maybe tell if
tis is OK or should be done in a different way.
Change-Id: Ia844b0aded97220df7f4605fdcffeac5e2270db3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173826
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
+ Upper-case for Delete Index
+ User-Defined amended with Index
Change-Id: I972ee22fa3681a0f1159426836a0ec1b83fa5e3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173849
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
This is meant to avoid copy&paste while keeping the public interface
template-free.
Change-Id: I3bc27d35b135df1693737de6b0e02444a06e4cbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Improved UNO API RuntimeException to return descriptive message.
Change-Id: Idae14c2ae095270c30b86cfad64936ccead5e4d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173686
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
When moving to the left, the RowInfo may have e.g. cells 21 to 41,
and rParam.mnX may be 15, which is outside of the RowInfo data.
It seems that in this case, when we handle the data outside of
the visible area, setting clip marks may be safely skipped anyway.
Change-Id: I2f507dc166468c44e34645bc34c827456f1ab1ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173857
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Small tweak to the kashida insertion rules to restore some previous
behavior. Kashida should not be inserted after a final Yeh, but should
be inserted after an initial or medial Seen, even if it is followed by a
final Yeh.
Change-Id: I1fef2d32961c6f55006b2df456827588f62af40b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173889
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
This change partially reverts the fix for tdf#65344, to allow more
candidate kashida insertion positions.
The final position fallback from the original ruleset has been restored.
Instead, tdf#65344 is now fixed by explicitly prohibiting kashida under
a final-position Yeh.
Change-Id: I9fe8c656768777c160205ad9892f2fe916a2a926
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173887
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
