This is a follow up to commit
55e86edcb3 to fix a crash that occurs
when importing a Basic library.
The change made to functions arguments passed to ImportLib in PS28
requires they be checked for nullptr before use. For further
understanding please see change to moduldl2.cxx at https://
gerrit.libreoffice.org/c/core/+/176254/27..28
Change-Id: I3f7ccc46134ddd2429c499d6e728e30331b51d7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177924
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
dialog contains percent symbols instead Cyrillic
Additionally use the same approach to make the expected symbols
appear in the description text view.
Change-Id: I89adafde4305dbe9a6e56481ed246376bc1d94a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177925
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
there is intended to be no logic change here, just rearrangement
and acknowledgement that SwOutlineNodesInline::Seek_Entry always
sets nEndPosInline to some value.
Change-Id: I10d694e20c8619ae297a61f612590556c9a9effa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178037
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Now when version 25.8 is in development, and the drop of legacy Windows
versions was announced in release notes.
Change-Id: Iefda63a29cafe40aec78d149067bdd7a3f20cffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178025
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This is independent of the selection.
(For selection, there is weld::TreeView::select
and weld::TreeView::get_selected_index instead.)
Change-Id: I3698a080cebaf4411740b0e7a95c54743e84d881
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178024
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Rename weld::TreeView member + methods to clarify
that these are about selection changes:
* m_aChangeHdl to m_aSelectionChangedHdl,
* signal_changed to signal_selection_changed
* connect_changed to connect_selection_changed
In GtkInstanceTreeview, also rename the
related methods calling signal_selection_changed
accordingly for consistency.
Change-Id: I299d7930484677395a0bdd0ff105df18688f2e04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178023
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
... to avoid own mutexes in own name container implementation.
Change-Id: I29ff6ef987154359c35d0628d529b0606ef08c5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177637
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When a frame is hidden, don't consider it when evaluating keep-with-next
attributes - this was the case for content in hidden sections before
commit 0c96119895
~SwFrameNotify() invalidating position of hidden frame with keep
attribute causes layout loops.
Also skip hidden frames in SwFlowFrame::IsKeepFwdMoveAllowed(),
SwFlowFrame::CheckKeep(), SwFlowFrame::IsPrevObjMove(),
SwFlowFrame::MoveBwd(), CalcContent().
Change-Id: I68556ba0a8e016d962399f3ce199e5eda0378867
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177975
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Open the bugdoc, go to the page after the section break, there is a top
margin for the first paragraph there in Word, but not in Writer.
This went wrong in commit abd90828cf
(tdf#160952 sw: ignore top margin of para on non-first pages with newer
DOCX, 2024-05-14), where it seemed that all implicit and explicit page
breaks want to ignore that top margin for the first paragraph.
Turns out this is more complex: implicit breaks and page breaks should
be followed by an ignore, but not paragraphs after "section break (next
page)". So restore the margins for the RES_PAGEDESC, but continue to
have them for RES_BREAK & implicit breaks.
Change-Id: If1fcf3077b81a705d3587bdae422dcfa16f1c17c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177973
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
When live resizing a window, replacing the CAMetalLayer with each
resize event repaints the window's background which causes a
noticeable flicker. So reuse any existing CAMetalLayer already
assigned to the native view.
Change-Id: I03bda5f0d40b84606b6602961e5f0d3b0dfcc6ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177921
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
The size of the value field is now set to 5 rows.
Change-Id: I808ffbb64d71a0707857cf80d1c0b73419ac7b90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177893
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Commit c83d241eff "tdf#154933 Rename "Text
Body" para style to "Body Text"" introduced a regression when importing
certain ODF documents, but the problem is actually pre-existing.
What happens is that first the built-in "Text body" style is created,
and then a non-built-in style with the same translated name as "Text
body" is imported, and instead of creating a new style, the built-in one
is found and used, and so its properties are overwritten.
The root cause is that SwStyleNameMapper::FillProgName() and in
particular SwStyleNameMapper::FillUIName() are defined poorly, ever
since they were introduced in 2001 in commit
4fbc9dd48b
It becomes obvious relatively quickly that the way style names work is
that at the UNO API level, the "ProgName" (internal, non-localised)
names are used, and at the core document level, the "UIName" (localised)
names are used.
This is in itself questionable - why is the translation from ProgName to
UIName not done in the UI? - but also very expensive to change now.
So then the UNO services are responsible for translating between
ProgName and UIName.
But the 2 functions don't do that properly; both need to check if the
given name is a known ProgName *or* a known UIName, and rename it in
case it collides with a known target name; also the 2 functions need to
cancel each other out, not add " (user)" at the end in both directions.
Fixing this causes numerous tests to fail, due to:
1. the UNO services calling themselves with already converted style
names, which are then translated a second time, which fails now.
(or calling the wrong function like SwXStyleFamily::getByIndex())
2. many tests call the UNO API with UINames instead of ProgNames
3. somehow the writerfilter import is also changed, causing failures in
e.g. testTdf113182 and testTdf104492
4. buggy code elsewhere (lcl_getUsedPageStyles()), problem similar to
1., for PageDescs
5. potentially more buggy code yet to be discovered (definitely table
styles, forgot which test that was)
So limit this fix for now to only paragraph styles, and don't do it in
writerfilter import, now at least sw.check passes.
Change-Id: I5cbdf3e174622e83f9af8787c3671b88c0e37bac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177858
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Tested-by: Jenkins
V1048 The 'eAggFunc' variable was assigned the same value. Will be assigned after the switch.
Change-Id: I21d4cb4b0e7427bea56598476ca176cc0a4f7124
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175902
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Declare support for the "Insert Breaks"
"File" -> Printer Settings" -> "Properties" 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.
Since this dialog contains tab pages, their .ui files
need to be declared as supported as well.
Change-Id: Ia4360eebf3fed6ab5f78510c866a1703b0db8998
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177923
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The current item and the selected item(s) are
not necessarily the same.
Looking into the gtk and VCL implementations,
weld::TreeView::signal_changed is called
when the selection (not the current item) changes, so
connect to the QItemSelectionModel::selectionChanged signal
instead of the QItemSelectionModel::currentChanged one
in the Qt implementation.
At the point in time that the QItemSelectionModel::selectionChanged
signal gets emitted, QItemSelectionModel::selectedIndexes
returns the newly selected indices while that was not
yet the case with QItemSelectionModel::currentChanged.
For the "Device" tab in the "File" -> "Printer Settings" -> "Properties"
dialog (for which support will be added in an upcoming commit),
this resulted in the PPD values (in the tree view
on the right) not being shown for the actually selected PPD
option/key (in the left tree view), but for the
one selected previously.
(See RTSDevicePage::SelectHdl for the logic filling
the tree view with items, which gets triggered when
weld::TreeView::signal_changed gets called.)
Change-Id: I31ec5aaaa47cd3d4704f25086b24645fb708be0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177922
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Similar to the check done in SwEditWin::MouseButtonDown.
Change-Id: I1a1b8966502a6b1557d424f28cfc1c1ecdf4b65e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177930
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Due to formatting, grapheme clusters can possibly be split across
multiple layouts. Layouts containing split grapheme clusters are created
by laying out the complete string, and extracting only the necessary
glyphs based on source codepoint index.
This approach is good enough for most diacritic cases, but it cannot
handle certain substitution cases where glyphs with advances would be
interleaved with other layouts. Sub-layouts must be contiguous.
This change introduces code to disable grapheme cluster splitting in
these cases that cannot be handled correctly.
Change-Id: I122abbf9c3f8a5efa4c72ad47991d0ad9ff8a8c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177927
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Used e.g. in RTSDevicePage::FillValueBox
(i.e. in the "File" -> "Printer Settings" -> "Properties"
dialog).
Change-Id: Ice39b266b366a6fd6b37b6ece28cee529990dc80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177909
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
