Trying to move the current cursor, which may actually be a selection,
to find next/prev footnore, may try to expand the selection across a
table boundary (from outside to inside), which would fail. This was
incorrectly treated as "there's no next/prev footnote, the cursor is
unchanged" case, and the cursor wasn't restored.
Use a separate local cursor object for testing; and make it at least
somewhat useful, to detect the case when there's no more footnotes
in the document, so the prev/next buttons would get disabled.
Change-Id: I7db100dfdd290fe01b3eebe17f1dec2784315243
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176399
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Since
commit a6ad198d09
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Sat Aug 17 13:19:54 2024 +0200
tdf#158556 use more comphelper::ByteReader
V1022 An exception was thrown by pointer. Consider throwing it by value instead.
Change-Id: I9218d79097975e47822f48838472ca2096d527d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176398
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Since
commit 2a2c4dddf5
Author: Andreas Heinisch <andreas.heinisch@yahoo.de>
Date: Tue Oct 29 12:11:41 2024 +0100
tdf#153636 - Search for outline node only if index is for the current chapter
Change-Id: If969db7c4eee4c542ff99f9d405aa7f1d2a8f414
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176403
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
V688 The 'nNegativeFormat' function argument possesses the same name as one of the class members, which can result in a confusion.
Change-Id: Ia558367b2325820f1cdeedcd92a7a0e663cf9f15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176402
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The 'm_pControlNumberStyles' pointer was not released in destructor. A memory leak is possible.
Change-Id: Ie60806814ec65b73d0eaf07b53e7dc133b33bf24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176396
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
V1044 Loop break conditions do not depend on the number of iterations.
Change-Id: Id43a749c090d26b6db174a1ad44df904d20863d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176397
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
because method is final after
commit 5b2cd79ade "loplugin:finalmethods"
Change-Id: Ib530133c42343a512497df012e3d7ed21a8d96bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176378
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... compressed size = 0.
The problem is that vector::data() on a vector of size 0 returns
nullptr, and osl_readFile into a nullptr buffer returns E_INVAL, which
causes an exception to be thrown.
Catch the exception, so that there is a chance to read the values from
the data descriptor instead.
(regression from commit 32cad89592
and/or commit a6ad198d09)
Change-Id: I9b2d9a930997146faf224d8033955b142fe93f58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176289
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
This is effectively the weld::Dialog equivalent of
Change-Id: Ia839fac90ea93b9ac6be5819aa4bb3261a775f33
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Sun Nov 10 23:01:07 2024 +0100
vcl: Return unique_ptr in weld::MessageDialog::weld_message_area
Change-Id: I3eee2d3617c3576b442a5578090cd5de53e17f33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176365
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The returned weld::Container* (but not the associated toolkit
widget) is owned by the caller.
Make that more obvious by returning a unique_ptr<weld::Container>
instead of a raw pointer.
This is also consistent with what other methods returning
instances for which the caller takes over ownership
(like weld::Widget::weld_parent) do, whereas
e.g. weld::Notebook::get_page returns a weld::Container*
that is owned by the weld::Notebook instance, not the caller.
Change-Id: Ia839fac90ea93b9ac6be5819aa4bb3261a775f33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176363
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move VclBuilder::handleMenuObject to the WidgetBuilder template
base class, and add a new purely virtual WidgetBuilder::insertMenuObject
that the existing VclBuilder equivalent now overrides.
This moves the remaining XML parsing logic from VclBuilder
to one of the base classes (WidgetBuilder, BuilderBase),
following the approach outlined in
commit f61ecf2563
Author: OmkarAcharekar <omkaracharekar12@gmail.com>
Date: Fri Sep 20 13:33:01 2024 +0200
tdf#130857 refactor VclBuilder: Extract template base class
Update the source code comments accordingly.
For QtBuilder, initially add a dummy implementation
that simply triggers an assert, but can be adjusted
in the future to create native Qt menus.
Change-Id: I3147cac28c7273cd4c4ea7344a083cd66af8337f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176362
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Move VclBuilder::handleMenu and VclBuilder::handleMenuChild
to the base class WidgetBuilder and add a new virtual
WidgetBuilder::handleMenuObject method (used by
WidgetBuilder::handleMenuChild) that
the existing VclBuilder implementation now overrides.
This prepares for allowing to use this by subclasses
that create menus other than the VCL PopupMenu and
continues the intended separation between XML parsing
done in WidgetBuilder and actual widget creation
(in subclasses implementing the vcl::Window or toolkit
specific logic.)
Change-Id: Idc896570e4b21f6997e548b7bdab8a9610042bff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176361
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add a new purely virtual WidgetBuilder::createMenu
and use that in VclBuilder::handleMenu instead
of directly calling VclPtr<PopupMenu>::Create there.
This is in preparation of moving
VclBuilder::handleMenu to WidgetBuilder as well,
to make it reusable for other child classes, in
particular QtBuilder.
Change-Id: Icf3f937ea8e876c8393185e41a95e0f66458ce11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176360
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Move the MenuAndId struct and the `m_aMenus` member from
VclBuilder to the WidgetBuilder base class and add two template
parameters `MenuClass` and `MenuPtr`, which VclBuilder
specializes with `PopupMenu` and `VclPtr<PopupMenu>`,
effectively leaving the logic unchanged.
Move VclBuilder::get_menu accordingly.
For QtBuilder, use `QMenu` and `QMenu*` for
the new template class parameters.
This can be used to implement support for
native Qt menus in the future.
Change-Id: Ib015b1b1e6968338ed7419b1822665a521ca748d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176359
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Now that GtkMenuBar support was dropped in
Change-Id: I550c83c6d5d13a5e45dc9332e981bae8b0f0a9a3
commit fa245e4eea218b3c707998e597c526b9d1fdb508
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Sun Nov 10 20:24:11 2024 +0100
tdf#130857 VclBuilder: Drop unused "GtkMenuBar" support
, use PopupMenu directly in MenuAndId instead of just the
Menu base class, which makes it unnecessary to cast when
a PopupMenu is wanted.
Change-Id: I51a44f219970f29a12aa15ee58e8512c62fca43e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176358
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The last use of a "GtkMenuBar" object in .ui files
was dropped in
commit 7b4169c9d5
Date: Wed Jun 9 01:56:48 2021 +0530
Implement Interface for Data Providers.
Drop the code handling it, to simplify the existing code
and an upcoming refactoring.
Change-Id: I550c83c6d5d13a5e45dc9332e981bae8b0f0a9a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176357
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Call the corresponding handlers to notify about
the previous and current tab page when switching
the tab page in QtInstanceNotebook, by remembering
the identifier of the current page and using that
in a slot connected to the QTabWidget::currentChanged
signal.
Change-Id: I387c75b3af138cf9b89f169f0a3c223c262c2a92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176356
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Declare support for the Writer "Tools" ->
"Footnote/Endnote Settings" dialog.
This means that native Qt widgets are used for that dialog
now when using the qt5 or qt6 VCL plugin and starting LO with
environment variable SAL_VCL_QT_USE_WELDED_WIDGETS=1 set.
This is the first supported dialog making use of "GtkNotebook"/
QtInstanceNotebook, i.e. of what was implemented in previous commit
Change-Id: I52e11ecf053a48940b88b7e6d1e6f9ba8778d9bb
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Sun Nov 10 18:54:28 2024 +0100
tdf#130857 qt weld: Implement QtInstanceNotebook logic
For such dialogs, support doesn't only need to be declared for
the dialog's top-level .ui file ("modules/swriter/ui/footendnotedialog.ui"),
but also for the .ui files of the single tab pages
(s. SwEndNoteOptionPage::SwEndNoteOptionPage), otherwise
the tab page content isn't shown.
Change-Id: Icb8c05cf0616651ae811185095232716bea21bcf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176354
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Implement all of the QtInstanceNotebook methods,
see also GtkInstanceNotebook and SalInstanceNotebook
for the gtk3 and VCL implementations for comparison.
Unlike weld::Notebook, QTabWidget doesn't have the
concept of IDs for tabs in addition to indices.
Introduce a PROPERTY_TAB_PAGE_ID property that
gets set on the widget of the corresponding tabs
and holds the tab identifier in order to support
that.
Implement QtBuilder::applyTabChildProperties
to set the tab label and ID property by using
the newly introduced QtInstanceNotebook::setTabIdAndLabel,
so only QtInstanceNotebook needs to handle that
property.
The weld::Container* returned by QtInstanceNotebook::get_page
is owned by QtInstanceNotebook, so keep create one
on demand and keep a mapping between tab pages and
the corresponding weld::Container.
In QtInstanceNotebook::insert_page, create a new
widget and set a QVBoxLayout for now. That could
be changed to use a different QLayout class in the
future if that turns out to be more useful.
In QtBuilder::makeObject, as the tab pages are children
of the "GtkNotebook" in the .ui file, they are initially
created as child widgets of the QTabWidget.
However, they need to be set via QTabWidget::setTab instead,
so add special handling for that case towards the end and
unset the parent relationship and call that method.
Change-Id: I52e11ecf053a48940b88b7e6d1e6f9ba8778d9bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176353
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Add asserts, so that it becomes clear if any dialog
wants to use logic that's not implemented yet, rather
than just not doing what was requested.
This helps prioritize what to implement while
adding support for more dialogs.
Change-Id: Iee708d96260d836879974b65e240ba7343b205f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176351
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
