Age | Commit message (Collapse) | Author |
|
Change-Id: I4d062f054a5ef6da7ef595190a7b3c6e2a0b191e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104865
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
tdf#137790 calc: set minimal line width: unit test
Change-Id: Idac7c23e55b3c4ee94790458fca5e7a7a5522098
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105301
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105409
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Otherwise glade-ui code gets confused to find controls
it never generated.
Change-Id: Iaf9a6e6aa5080f7a49bb754fe967e6a85e80cfae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105572
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Recent GCC 10 trunk warns (when LO is configured with --enable-optimized):
> In file included from lt-script-db.c:24:
> lt-script-db.c: In function ‘lt_script_db_parse.constprop’:
> lt-messages.h:105:2: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
> 105 | lt_message_printf(LT_MSG_WARNING, \
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 106 | LT_MSG_FLAG_NONE, \
> | ~~~~~~~~~~~~~~~~~~~
> 107 | 0, \
> | ~~~~~~
> 108 | __VA_ARGS__)
> | ~~~~~~~~~~~~
> lt-script-db.c:137:4: note: in expansion of macro ‘lt_warning’
> 137 | lt_warning("No subtag node: description = '%s'",
> | ^~~~~~~~~~
> lt-script-db.c:137:47: note: format string is defined here
> 137 | lt_warning("No subtag node: description = '%s'",
> | ^~
Change-Id: I2924f7aab84f4f2640f277ee5c2689753627ae78
Reviewed-on: https://gerrit.libreoffice.org/83869
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 047e8ae5d189f030d565b13f97a4d6a45b00e6be)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105557
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
move the frame cleanup into a helper that listens to see if it got
disposed by the preview itself
Change-Id: I523285268118300f18b0f0f0a10fab7a9cced9c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105221
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit a986db4b2d24669e502e447036851e118cc23036)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105349
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Previous exception (std::out_of_range) was not catch in case
of invalid RTF imported: wrapping code checks only for
uno::exception. This is not a case for loading file, but
for parsing of clipboard containing invalid RTF it was causing
fatal error, freeze and/or LO crash due to unhandled exception.
I think there is no reason to add generic processing for
std::exception in RTF filter: this can complicate diagnosing
other potential problems. Instead let's throw UNO exception,
like in other parts of RTF filter code.
Change-Id: I064bbdc1559cc7700c96dbbeaf2911a2c8e0421e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105285
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 0d84e4bed71a1083c5189408aea5922a34b40686)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105227
Tested-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102319
Tested-by: Jenkins
Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
(cherry picked from commit d435997f446941adaa76fe4b253946cd08861ffd)
Change-Id: I450625ccac06aec54371ede6bf9b50a221e1ba8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104936
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Ia88e28b1569ea69df81d905cb76a6791a887ef3f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101883
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit b6ab2330d97672936edc56de8d6f5b6f772908ff)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104941
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
... at the start if the section nodes were at the start.
m_bBackSp and m_bJoinNext can't both be true.
(regression from 740f1796504f66408b692225a9676c9ee3d63722)
Change-Id: I999ed3809ca8f527bc3e754b229df02da4576825
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104891
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit c4967928475f2be20ac2d79e3fa84ac435a7e560)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104920
Tested-by: Michael Stahl <michael.stahl@cib.de>
|
|
We had some seldom build failures on Windows, with errors like:
PermissionError: [WinError 32] The process cannot access the file
because it is being used by another process: '..../nssckmdt.h'.
This happens, because of the "." / parent shell hack. Thinking
about it again, it doesn't prevent the parent make to run in
parallel to the "." directory make. So I tried to use a terminal
match-all rule like
ifneq (,$(filter .,$(DIRS)))
%::
# empty terminal rule triggered
$(error can't happen)
endif
to stop the original parent make, but that doesn't work and the
$(error ...) is triggered.
So AFAIK I'm out of options here and have to restore the old
manual pre-dependency build variant - still much better then no
parallel build.
An alternative idea was to put the rest of the rules.mk in the
"else" of the terminal rule, to skip all normal rules, but this
still leaves out all rules from the rest of the make-files,
which might result in some hard to debug errors.
This reverts my upstream patch 15608:744881490c78.
Change-Id: I9e2e9e1ec9f35697c7853c92f60434f514cba5ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103777
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit d2f9c55e065d559de903d540da28502646714a24)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104837
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
sw::DocumentContentOperationsManager::CopyImplImpl() is called with a
rPam that's on an SwOLENode.
The problem (which i can't reproduce in --enable-dbgutil build,
presumably for timing reasons) is that after the context menu pops up,
some idle layout runs and reformats the document and deletes a
SwFlyFrame and that calls SdrMarkView::UnmarkAllObj().
Then when SwFEShell::Copy() is called, it finds IsFrameSelected()
returns false, and it tries to copy normal text when the cursor is on
an SwOLENode.
Fix this in SwFlyFrame::FinitDrawObj() by first moving the cursor out
of any selected flys.
(regression from 81ec0039b2085faab49380c7a56af0c562d4c9e4
- previously CopyImplImpl() would return early)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104697
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit 40bff2567fa4a3fa8ec4445182cbbe3547c17410)
tdf#131679 sw: follow-up: Unmark before SetSelection()
Backporting this to 6.4, it crashes in CppunitTest_desktop_lib because
some sidebar is loaded from SwView::AttrChangedNotify()/SelectShell()
and that ends up calling SwView::StateTabWin() about 40 stack frames
later and this calls SwFEShell::GetAnyCurRect() which gets the still
selected fly but its page frame is null.
So make sure shells don't see the deleted fly.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104815
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit f63afb95b5c2d80d33a35820ef1d9abd9e70d3ca)
Change-Id: Id135fcc002c03c07c34fbdc0355f2895d8b6565b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104683
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I933537a44b9493adc89516bccb189003cf4f132f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101950
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit bc46ff73d6f79d850253f9e1896643eb73238ebb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104826
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I0ad6697d8dce814f20ea5f98e9c8f4b9c68f278d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99641
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit a206054ac048702d48077eea6f3d464c3d241ab3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104824
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I148052d7038824b43ec0c473d4bcbcb64e2f92b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103608
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit 416cb76758719b88a4cdefe8c9d16131c35cfdf5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104747
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I737296f1a0646065288be2cb0be3ef7f939fb536
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99878
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit 99284a22f3cda8518cd2207128928c2e455c89ee)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104825
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I6837968ee7cc5e4b3bc9abd7e320f562c6ff0833
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104619
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104715
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I3b5d1a2a2396fba9d350350ac4d04f7f97401ebe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96714
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit 8e4c79472644452431381733a5e4b21f98fcdcf3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104823
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
into distro/lhm/libreoffice-6-4+backports
Change-Id: Iaa36898716ff331e66592ce10bc1b7dacf1c75d1
|
|
This is a partial revert of LO 6.2
commit 2ec0cf500222aef55d02df80154b47fbb92970c9
I can't think of any excuse for how I possibly missed that
xDocProps was being defined/used outside of this clause.
Just plain stupid and blind.
The good news is that the create and modified date still
seem to be getting saved somehow/somewhere. So it isn't
the disaster that it looks like it could have been.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103565
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
(cherry picked from commit 1086654d6e8cc22f1f99195668db3f305437e570)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104495
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 19b8ded3ae18dd4070a3e21d7b980782a27e5547)
Change-Id: I72ef56fa50b9e92e4ce687b132b1919cfae6c1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104497
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Iaa1726883202c35a3d5ce76893f05de46551e672
(cherry picked from commit 6aa831bf46282d3df8b5f214abed7428bd4bd001)
|
|
* Update translations from branch 'libreoffice-6-4'
to a98a81ee9754921c9e3d306481e5db92514d7435
- update translations for 6.4.7 rc2
and force-fix errors using pocheck
Change-Id: I5b70ce184448b11dc7d76b84e5ad200a2d8f8474
|
|
Regression from commit 10bb02efd8afd42e633e370480104e2575546d8e
(tdf#129685 PPTX import: fix unexpected centering of shape text,
2020-09-18), now the problem was that some text should be left aligned,
but was centered.
Fix the problem by reverting most of the above commit: XML changes,
changes to SdImportTest::testTdf113198() (manual testing show that this
change is not needed after all) and changes to the
TextBodyPropertiesContext ctor in oox/ (but not the testcase itself).
Fix tdf#113198 again, this time in Shape::createAndInsert(), which is
meant to be closer to what the binary PPT import does.
With this, all cases from tdf#104722, tdf#113198, tdf#129685 and
tdf#137023 are meant to be handled correctly at the same time.
(cherry picked from commit dfa1856cdb4c69985ef1e809d33055427b6fbd76)
Change-Id: Id785252c26fc407cd74c9cfb55624091798d7773
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104006
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104023
|
|
It was lost with 1ae450504cf57457f9702684b1517fda1dd3c481
("drop gtk2 support"), which was based on an older revision
of gtksalmenu.cxx.
In the meantime, the UI for settings icons on was hidden
(see tdf#123265), but this can't be an excuse for carrying
the broken code. The setting is also still available as an
expert config.
Change-Id: Iffc6342bb312230646399f2f85ef0211315f6c8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103660
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
(cherry picked from commit 800baa9c60d8fb7b4ed8cf8ae0ba7b6b68c69c9c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103663
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I33cdfe07cc53b579bbe16486f302daf7bd3da841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103352
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103569
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I84bfd619b2f8802bc311eaa221670a9cae904160
(cherry picked from commit fb9b3e68dc4bf88a1a2764cbcd6420dc2a475220)
|
|
since...
commit b070202b420129b5edd368420e0e50ec45261d01
Date: Tue Nov 20 18:26:18 2018 +0100
sw_redlinehide_4a: SwEditShell::IsMoveLeftMargin(), MoveLeftMargin()
Change-Id: Ie28207747560153020341305015f1693f6ca9f50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103552
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit dc6e005c79b6c23b805dea44cd89fa83ea945f03)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103578
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
regression from
commit 4b2d4f3c4a68361a6bc03c9ab110ce9376b14b20
tdf#119227 fix freeze when copying a large bulleted list
Change-Id: I7d54b19c7a02c717426edce7896caaadf909154e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102000
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
(cherry picked from commit 18e4367c33f327cf09985105bde583cdcc7b2a46)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101972
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 9ec49c6c2dd58eb60ca0ac5e99edee9ee098302a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103581
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
probably since...
commit a573b8b21688d9681f4fa129ec37cf89954e9d1c
Date: Sat May 21 16:14:56 2011 -0430
Replace List for std::vector in SfxStringListItem.
Change-Id: I7060b5693ba08fa5f70cc5cb3ae1b7a4722a31a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103340
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
(cherry picked from commit 7c8f997321e136208e8983ab6ad78cc33891125f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103572
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Necessary to also adapt the test case that checks for a defined
number of styles.
Regression from
commit 7b0aed617f1e57335837cf56ef2d222a96f8270d
CommitDate: Wed Sep 28 11:42:56 2016 +0000
Remove old cell styles from calc
and
commit 06f319937187f76ee402d53b3baa78c391c2af19
CommitDate: Sun Oct 2 13:51:26 2016 +0000
tdf#90937 Add a set of cell styles to calc
Change-Id: I3e47d8e24d375a64d9056e7a85197b89173c8e41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103520
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
(cherry picked from commit 930d82550863430c9bef96ac307c3ff2cfefe4d8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103433
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I789adaf699a857e28416132d253c04128def5984
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97481
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit 189086209113a20a36ad43d19e53af6678ff772c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104822
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Iec50c3129097e99ae57543601d40c5a380db678f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104391
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit c143ad222a3c4c8d86699e1b3f20d3a5262da1e2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104746
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Ib25d5723057b79f49876df816bff5971ee3fa7c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104444
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit 254c26f1c69e2eb23f66a79349b0ea78a5d467d3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104745
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I1a9b0a1150f8e3e1832aaa15a09049622bd83afc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96592
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
(cherry picked from commit 9197a52c1bd79bbdc0756724c74fd2a679b9f626)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104744
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
When the Java framework's direct mode is used,
there is no use in allowing the user to change the Java
options in the "Advanced" options page, so the corresponding
frame is grayed out, s. commit
2976590ed9f727c24064c97d80a51e9891253119
("Gray out Java options when framework's direct mode is used",
2020-10-21).
For the native gtk3 implementation, this also means that the
child widget holding the list of JREs ('m_xJavaList')
automatically remains grayed out as long as the parent widget
('m_xJavaFrame') is.
However, it turns out that this is not true for the
plain VCL implementation (used e.g. by the gen or kf5 VCL
plugins) where the child widget can be
made sensitive while the parent widget is insensitive.
Therefore, commit 3935a0bd3bcf747aa9bede59b045d23ab598f2d4
("Properly (un)tick Java checkbox in Java options in direct
mode", 2020-10-21) resulted in the widget holding the
list of JREs becoming active again when the
'EnableHdl_Impl' handler was called in the non-gtk3 case
(while the parent widget and the buttons to add JREs, edit
Java parameters and classpath would remained grayed out).
Make sure the widget holding the list of JREs remains
grayed out along with the whole frame holding the Java
options.
Change-Id: Ic46bf317afec9bc566493ec56ab5319a78050da0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104669
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
While the Java settings cannot be changed when the direct mode
of the Java framework is used
(s. Change-ID Ife017f9b5c6c6488f84201dd78b23305c67bec1b,
"Gray out Java options when framework's direct mode is used"),
it still makes sense to (un)tick the (grayed out) checkbox which
indicates whether a JRE is used or not, which depends on whether
the JRE that is set (e.g. via env variable
'UNO_JAVA_JFW_JREHOME') is usable or not.
Change-Id: I13822bb7535e3f05cbc6ef83b3c82e2739c45ad6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104064
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
(cherry picked from commit 330b89c211fcf0f852fb55e51721b1d4f0bb853d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104607
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
The 'javasettings_${_OS}_${_ARCH}.xml' files are only
meant to be used when the application mode of the
Java framework is used, not in direct mode.
From ure/source/README:
> You can also use the
> UNO_JAVA_JFW_JREHOME deployment variable to specify the location of a JDK/JRE
> installation. For more information on this variable, see
> http://udk.openoffice.org/common/man/spec/javavendorextension.sxw.
From that http://udk.openoffice.org/common/man/spec/javavendorextension.sxw :
> The direct mode of the framework is used within the build environment.
> Java is needed there in order to register Java UNO components with the
> regcomp tool. Direct mode means that no settings are written or read.
> That is the parameters UNO_JAVA_JFW_USER_DATA and
> UNO_JAVA_JFW_SHARED_DATA are not used.
> [...]
> Another example for using the direct mode is the SDK. The SDK uses the
> libraries from the office installation. When an SDK is configured then
> one specifies what Java is to be used. This Java shall then be used for
> all task which require Java including registration of UNO components. In
> order to override the java settings of the office the script which
> prepares the SDK environment sets these environment variables:
> UNO_JAVA_JFW_JREHOME=<file_URL_to_selected_Java>
> UNO_JAVA_JFW_ENV_CLASSPATH=true
> UNO_JAVA_JFW_VENDOR_SETTINGS=<file_URL_to_javavendors.xml_from_OOo>
> By setting UNO_JAVA_JFW_JREHOME the framework is switched into direct mode
> and the office settings are disregarded.
Therefore, gray out the Java options in the "Advanced" page in "Tools"
-> "Options" to not give the user the wrong impression that settings
made there actually have any effect when using direct mode, e.g. by
starting LibreOffice like this
UNO_JAVA_JFW_JREHOME=file:///usr/lib/jvm/java-11-openjdk-amd64/ ./instdir/program/soffice --writer
and then realizing on restart that all manually made settings
were discarded (e.g. newly added Java installation does not
show up,...).
Change-Id: Ife017f9b5c6c6488f84201dd78b23305c67bec1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104002
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
(cherry picked from commit 2976590ed9f727c24064c97d80a51e9891253119)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104601
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
The 'javasettings_${_OS}_${_ARCH}.xml' files are only
meant to be used when the application mode of the
Java framework is used, not in direct mode.
From ure/source/README:
> You can also use the
> UNO_JAVA_JFW_JREHOME deployment variable to specify the location of a JDK/JRE
> installation. For more information on this variable, see
> http://udk.openoffice.org/common/man/spec/javavendorextension.sxw.
From that http://udk.openoffice.org/common/man/spec/javavendorextension.sxw :
> The direct mode of the framework is used within the build environment.
> Java is needed there in order to register Java UNO components with the
> regcomp tool. Direct mode means that no settings are written or read.
> That is the parameters UNO_JAVA_JFW_USER_DATA and
> UNO_JAVA_JFW_SHARED_DATA are not used.
> [...]
> Another example for using the direct mode is the SDK. The SDK uses the
> libraries from the office installation. When an SDK is configured then
> one specifies what Java is to be used. This Java shall then be used for
> all task which require Java including registration of UNO components. In
> order to override the java settings of the office the script which
> prepares the SDK environment sets these environment variables:
> UNO_JAVA_JFW_JREHOME=<file_URL_to_selected_Java>
> UNO_JAVA_JFW_ENV_CLASSPATH=true
> UNO_JAVA_JFW_VENDOR_SETTINGS=<file_URL_to_javavendors.xml_from_OOo>
> By setting UNO_JAVA_JFW_JREHOME the framework is switched into direct mode
> and the office settings are disregarded.
Therefore, don't try to read the settings when using direct mode.
This makes the relevant code path for accessing the settings conditional
on 'jfw::JFW_MODE_APPLICATION' being used.
Otherwise, using direct mode e.g. by starting LibreOffice using
UNO_JAVA_JFW_JREHOME=file:///usr/lib/jvm/java-11-openjdk-amd64/ ./instdir/program/soffice --writer
then going to the "Advanced" options in "Tools" -> "Options", where
the Java settings reside would result in this SAL_WARN being triggered
warn:jfw:10207:10207:jvmfwk/source/framework.cxx:119: [Java framework] Trying to access settings files in direct mode.
and no JVM at all being shown in the list of available
Java installations.
Change-Id: I2b98d822aed2b160f970c50ca695a9f3beeacd34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104001
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
(cherry picked from commit 903a5aca86b41cd6c3d814af8bdd60b6885d300b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104600
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This is a partial revert of LO 6.2
commit 2ec0cf500222aef55d02df80154b47fbb92970c9
I can't think of any excuse for how I possibly missed that
xDocProps was being defined/used outside of this clause.
Just plain stupid and blind.
The good news is that the create and modified date still
seem to be getting saved somehow/somewhere. So it isn't
the disaster that it looks like it could have been.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103565
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
(cherry picked from commit 1086654d6e8cc22f1f99195668db3f305437e570)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104495
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 19b8ded3ae18dd4070a3e21d7b980782a27e5547)
Change-Id: I72ef56fa50b9e92e4ce687b132b1919cfae6c1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104497
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
First init m_nDeleteTextNodes, then check it; it is inited to 1 in the
ctor so the ++m_nSttNode was skipped.
This then caused bJoinNext to be true in UndoImpl() when it should
be false.
(regression from dc7e7b94a7211c576454267c09eb108e761e4487)
Change-Id: I74038ef7f8036581dd77341dc8372e87139bdb6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104433
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit 7221b7638c74b13e229f7ff50349a253ebb74cfc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104344
Tested-by: Michael Stahl <michael.stahl@cib.de>
|
|
Since commit e1629c210ad78310e3d48c0756723134a27b89df ReplaceRange()
will preserve flys, so split the delete into a DeleteAndJoin() just to
join the paragraphs - which should not delete any flys because it
doesn't include the "---" so isn't at the end of the section - and
a ReplaceRange for the "---".
(regression from 28b77c89dfcafae82cf2a6d85731b643ff9290e5
and e75dd1fc992f168f24d66595265a978071cdd277)
Change-Id: Ib995e41649f69963c823a463538958d533082ee7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104380
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit 9b34dc20b6946698ae6ce2d5d859885bfb444633)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104335
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 3f554879aa90a73940041e3a1217b97a15e18bc3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104339
Tested-by: Michael Stahl <michael.stahl@cib.de>
|
|
The UI doesn't allow to replace an empty selection anyway, but it now
happens on Undo.
(regression from e1629c210ad78310e3d48c0756723134a27b89df)
Change-Id: I468f28335beaeb8c42df8ed4cfc90f2c03129239
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104308
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit d3eca4177a78c3db17b4699ea6e071e52488c46f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104305
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit ba5584a3ce86c2db52e2e4a4b91254741b2616ec)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104333
Tested-by: Michael Stahl <michael.stahl@cib.de>
|
|
The problem with the fix for tdf#127635 is that now the cursor doesn't
move left on backspace if change tracking is on.
(regression from 398ba26077f9029bdf6f7378bfc9ce8376b6f02d)
Revert that and fix the autocorrect position in SwWrtShell::Insert()
instead.
Change-Id: I5989a589b654fc6e5ba3dd66922af15eff758ecc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104280
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit be4616d6b49b8c9cf1a90b212b24ead3dabcab6c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104299
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 10c638e520096a0cc282d91ac2a447509f674a6f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104332
Tested-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I444997a6cc55cfe287f4c610f538f2f54803646c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104085
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104319
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Bug happens in the "top" branch of SplitContentNode().
SwTextNode::CutImpl() sends several hints to the SwTextFrame so that it
invalidates itself; a SwInsText and a SwDelText most prominently.
The SwInsText won't have an effect because the target node doesn't have
text frames yet, but the SwDelText should be sufficient to update the
text frames' MergedPara and invalidate the text frames.
The MergedPara is re-created by SwTextFrame::RegisterToNode() anyway,
but that *doesn't* invalidate the SwTextFrame.
Then an additional SwDelText is sent, which will *not* invalidate the
SwTextFrame, because its MergedPara is up-to-date so nothing gets
deleted by the hint.
It's unclear why the LockModify() is done here, since CVS initial
import, perhaps it's some premature optimization; try to remove the
manual sending of SwDelText and just let CutImpl() do it.
Also remove an odd assert in UpdateMergedParaForMove() that i don't
understand the reason for now.
Change-Id: Iba7196556f614356dba4def74f039a88f392eb0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104219
Tested-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit fefc0dfdcedbd0ef9d32c32be356f8086e756b33)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104252
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 6600403ad3f743c16eb4aef33627e7dbce3b153d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104291
|
|
Change-Id: Iaa1726883202c35a3d5ce76893f05de46551e672
(cherry picked from commit 6aa831bf46282d3df8b5f214abed7428bd4bd001)
|
|
* Update translations from branch 'libreoffice-6-4'
to a98a81ee9754921c9e3d306481e5db92514d7435
- update translations for 6.4.7 rc2
and force-fix errors using pocheck
Change-Id: I5b70ce184448b11dc7d76b84e5ad200a2d8f8474
|
|
Regression from commit 10bb02efd8afd42e633e370480104e2575546d8e
(tdf#129685 PPTX import: fix unexpected centering of shape text,
2020-09-18), now the problem was that some text should be left aligned,
but was centered.
Fix the problem by reverting most of the above commit: XML changes,
changes to SdImportTest::testTdf113198() (manual testing show that this
change is not needed after all) and changes to the
TextBodyPropertiesContext ctor in oox/ (but not the testcase itself).
Fix tdf#113198 again, this time in Shape::createAndInsert(), which is
meant to be closer to what the binary PPT import does.
With this, all cases from tdf#104722, tdf#113198, tdf#129685 and
tdf#137023 are meant to be handled correctly at the same time.
(cherry picked from commit dfa1856cdb4c69985ef1e809d33055427b6fbd76)
Change-Id: Id785252c26fc407cd74c9cfb55624091798d7773
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104006
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104023
|
|
UNO dialogs since LibreOffice 4.0 permitted setting HScroll /
VScroll properties to enable scrolling for too large a content.
Conceptually clone this code over to TabPage as well, and register
necessary UNO properties in the toolkit UNO wrappers.
Add missing API documentation also to UnoControlDialogModel,
plus the new properties to the UnoControlTabPageModel.
Change-Id: Iff90f60d0152ca21e4fe61c31315b9e1feab0dea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103999
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
It was lost with 1ae450504cf57457f9702684b1517fda1dd3c481
("drop gtk2 support"), which was based on an older revision
of gtksalmenu.cxx.
In the meantime, the UI for settings icons on was hidden
(see tdf#123265), but this can't be an excuse for carrying
the broken code. The setting is also still available as an
expert config.
Change-Id: Iffc6342bb312230646399f2f85ef0211315f6c8a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103660
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
(cherry picked from commit 800baa9c60d8fb7b4ed8cf8ae0ba7b6b68c69c9c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103663
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I33cdfe07cc53b579bbe16486f302daf7bd3da841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103352
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103569
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I84bfd619b2f8802bc311eaa221670a9cae904160
(cherry picked from commit fb9b3e68dc4bf88a1a2764cbcd6420dc2a475220)
|