Age | Commit message (Collapse) | Author |
|
Change-Id: Ifdd3df50b98641785a4b1d258092efe531e98e7d
Reviewed-on: https://gerrit.libreoffice.org/72870
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie931fbec18b6b32b1f0f817df0e8a8ca31ca415a
Reviewed-on: https://gerrit.libreoffice.org/72864
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>
|
|
f9905401d8cf2d73576231ebd84cfa5f4f73bcac "tdf#125170 Deliver mouse events also
when clicking into document content" had disabled it because its
gerrit_linux_clang_dbgutil Jenkins build had failed it successively like
> LOG> Execute: Date
> LOG> try to set:
> LOG> old = com.sun.star.util.Date@271053e1{1, 1, 1800}
> LOG> new = com.sun.star.util.Date@589838eb{2, 0, 0}
> warn:tools.datetime:303:1063:tools/source/datetime/tdate.cxx:102: Date::setDateFromDMY - sure about 0 year? It's not in the calendar.
> LOG> Property Date is void
> LOG> Value for 'Date' hasn't changed as expected
> LOG> result = com.sun.star.util.Date@42dafa95{1, 1, 1800}
> Method Date finished with state FAILED
> LOG> Date: COMPLETED.FAILED
(<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/32715/>).
But it is unclear how that commit would have affected that test, and at least a
recent local build of mine succeeds with
> LOG> Execute: Date
> LOG> try to set:
> LOG> old = com.sun.star.util.Date@dc24521{0, 0, 0}
> LOG> new = com.sun.star.util.Date@10bdf5e5{1, 0, 0}
> warn:tools.datetime:10048:10220:tools/source/datetime/tdate.cxx:102: Date::setDateFromDMY - sure about 0 year? It's not in the calendar.
> LOG> Property Date is void
> LOG> Property 'Date' OK
> LOG> result = com.sun.star.util.Date@6e1ec318{1, 0, 0}
> Method Date finished with state OK
> LOG> Date: COMPLETED.OK
(note the difference of initial date, {1, 1, 1800} vs. {0, 0, 0}, whether or not
that is relevant), so lets re-enable the test for now and see...
Change-Id: I53b462954650e32de85c795c94f9b8038dc01918
Reviewed-on: https://gerrit.libreoffice.org/72863
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The parameter value for '--accept' is no UNO-Url, but uses a
similar syntax. This was wrongly changed in commit d78f29ab3f40
("tdf#100836 "Starting the LibreOffice Software With Parameters"
help update").
So this changes the parameter value back to {accept-string},
documents its syntax and adds some common examples.
Change-Id: If8159b1d982c54e3dca6d27a1c400d2450ff2d1e
Reviewed-on: https://gerrit.libreoffice.org/72859
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I570af8f19468730aad714425492f69d05c0a0cf3
Reviewed-on: https://gerrit.libreoffice.org/72852
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
see also tdf#40457, tdf#115032
Change-Id: I505c3dfaf8f0a23e525db015f52a881b22016d11
Reviewed-on: https://gerrit.libreoffice.org/72846
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia5d0623c51c259fdbc3cfbc1d4d2432439282bae
Reviewed-on: https://gerrit.libreoffice.org/72856
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I2aa6ead1a1c369a7111af69e75d7bb86f97a1734
Reviewed-on: https://gerrit.libreoffice.org/72862
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I3c012c0e8aea8b3f78b908e4182741d28c6ab2ce
Reviewed-on: https://gerrit.libreoffice.org/72869
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I329310930d30ddd9c13df6a62bf6220448d21d4f
Reviewed-on: https://gerrit.libreoffice.org/72835
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I4452913a149211f4d1fea2d667aac890916d9e42
Reviewed-on: https://gerrit.libreoffice.org/72876
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
At least some versions of GCC put the -gsplit-dwarf .dwo file in cwd when
compiling and linking is done together in one compiler invocation, see
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90575> "-gsplit-dwarf leaves
behind .dwo file in cwd".
Change-Id: I1b418e400a3e8107997fbbfd7f87ef3ac9fbbd28
Reviewed-on: https://gerrit.libreoffice.org/72841
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
regression from
commit f4ea84ff370d33a02a8fb1d6405b9d964491258e
Date: Thu Apr 25 16:35:14 2019 +0200
tdf#119650 slow saving spreadsheet with comments, part 1
Change-Id: I91b3c009fb8b6739e98537de227ab563828b9c80
Reviewed-on: https://gerrit.libreoffice.org/72842
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Seriously, such default values only serve to confuse the code reader.
Change-Id: I478442514baac3159ea0ae20132222ae58b38b8c
|
|
Now is the time to get it out of the blacklist
since it is a tiny class again.
And also remove some leftovers.
Change-Id: Ia38dd3054ddefa43a7e0d917d358e7d9d1b750e4
Reviewed-on: https://gerrit.libreoffice.org/72837
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
Change-Id: I2814c6b0ccb1198bc83f79e63a8a1713d8df32cd
Reviewed-on: https://gerrit.libreoffice.org/72834
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I340b1695588bea0f1ce15685731c522907fdb7ee
Reviewed-on: https://gerrit.libreoffice.org/72806
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I658773f4fc0409a73de56301f5457fa1fb9e4a28
Reviewed-on: https://gerrit.libreoffice.org/72805
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I9c348e34a07ab269217f35633cb3a54ea4f7cf68
Reviewed-on: https://gerrit.libreoffice.org/72804
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6d4aca59d5f9e24521876c36853b663b65a2d200
Reviewed-on: https://gerrit.libreoffice.org/72803
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I93f3dccb1aac4a018f5a5dd7af61024306099675
Reviewed-on: https://gerrit.libreoffice.org/72802
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I055f01d2ce462009986801d4a603b0b72b1a621c
Reviewed-on: https://gerrit.libreoffice.org/72787
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
otherwise the IMapWnd and CountourWindow don't accept the double-click
release as finishing polygon editing
Change-Id: Iaab7a46cad2c5c92fdc2f8ff61135792fae67be8
Reviewed-on: https://gerrit.libreoffice.org/72830
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
But some of those functions' names may be more telling than their configuration
property counterparts, so there may be merit in keeping those trivial wrapper
functions around.
Change-Id: Ibbf4965fcefd58649920fad964b4a8d2108deaca
Reviewed-on: https://gerrit.libreoffice.org/72836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as it does the same as the copy assignment op. And both of those are
apparently already only called with SolarMutex locked, so no need to lock it
again. So the copy assignment op (as well as the other special memeber
functions) can be left implicitly-declared. (And some uses of the original
takeOver can be optimized to use move assignment.)
Change-Id: I279a5e3ee85ff2342d6ef5f672108a0712fe116d
Reviewed-on: https://gerrit.libreoffice.org/72831
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
* Update helpcontent2 from branch 'master'
- Untangle Help Contents for Impress and Draw
Create a separated sdraw.tree for Contents and move entries
from Impress tree to Draw tree.
Common contents are maintained in both trees.
This is work in progress. Draw and Impress Help pages need update
especially for menus.
Change-Id: I179a5ee7407c4a8357a87b2e7a0d8782b7bb0520
Reviewed-on: https://gerrit.libreoffice.org/72693
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|
|
(but even better to actually use move assignment op)
Change-Id: I6d9c4a9568ef03d84b7acd48a129d0c723c915cb
Reviewed-on: https://gerrit.libreoffice.org/72820
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As per ESC & Design Team decisions.
It has become unusable anyway after major changes
on the Mozilla side.
Long live Libreoffice Themes! :)
Change-Id: I2893fbc5e4f5637ee9715fa426b92ca58534f126
Reviewed-on: https://gerrit.libreoffice.org/72811
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
Which allows not hardcoding true for LOK.
Change-Id: I644763ba052b148fc34283e361aa02f9bba2c5ee
Reviewed-on: https://gerrit.libreoffice.org/72832
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I3ecaea025fda7a4808f76a9ccda218225ddd38bd
Reviewed-on: https://gerrit.libreoffice.org/72808
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>
|
|
Change-Id: I363a02d7115ea54bb4aedb38071a249e145ee471
Reviewed-on: https://gerrit.libreoffice.org/72742
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
sooner or later someone is going to need more than 65535 redlines
Change-Id: I34a913a0beaac14b64b58964ace022210a8eac40
Reviewed-on: https://gerrit.libreoffice.org/72773
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and move the auto-format embedded flag to a separate field
Change-Id: I02155702389178fbfdf874f592d47a29f8759974
Reviewed-on: https://gerrit.libreoffice.org/72771
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Its PCHs are always different even if the source is the same (timestamps
somewhere?). But if the output of gcc -E for that precompiled header
source is the same, then technically the .gch should be without a change.
So this makes ccache get hits even if the .gch gets rebuilt, as long
as ccache is new enough to support CCACHE_PCH_EXTSUM (3.5+).
Change-Id: I447bb4840047f23deed55e25de1794047a0a9998
Reviewed-on: https://gerrit.libreoffice.org/72705
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
It's ridiculously un-cooperative, and if you accidentally run the script
from a static IP you won't be able to look at that bugzilla for a while,
which is tragic because it holds important historical info hostage.
Change-Id: I55887baceac82ad0a3bcedc3de9c9b3d0e02f9c3
Reviewed-on: https://gerrit.libreoffice.org/72220
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
The remaining problem is that with the previous commit, the layout stops
at some point and everything is crammed into the next-to-last page, with
the following symptom:
warn:legacy.osl:7667:7667:sw/source/core/layout/tabfrm.cxx:2642: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910
This is apparently because of some very funny recursion that goes in
circles until it formats some part of the "outer" table again.
0 SwTabFrame::MakeAll(OutputDevice*) (this=0x82b0280) at tabfrm.cxx:2642
^ mpUpper -> 928 - top-level SwTabFrame and m_pFollow of 905
1 SwFrame::PrepareMake(OutputDevice*) (this=0x82b0280) at calcmove.cxx:372
2 SwFrame::Calc(OutputDevice*) const (this=0x82b0280) at trvlfrm.cxx:1790
3 SwFrame::PrepareMake(OutputDevice*) (this=0x6c06ba0) at calcmove.cxx:247
4 SwFrame::Calc(OutputDevice*) const (this=0x6c06ba0) at trvlfrm.cxx:1790
5 SwFrame::PrepareMake(OutputDevice*) (this=0x82aebf0) at calcmove.cxx:247
6 SwFrame::Calc(OutputDevice*) const (this=0x82aebf0) at trvlfrm.cxx:1790
7 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:247
8 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790
^ m_pFollow->mpNext -> 332 - again! it's now m_pFollow->mpNext
9 SwTabFrame::MakeAll(OutputDevice*) (this=0x6d64570) at tabfrm.cxx:2544
^ 303 - nested SwTabFrame, used to precede 332 but has now split and its m_pFollow precedes 332
10 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:313
11 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790
^ 332 - SwTextFrame originally inside 991, but moved under top-level SwTabFrame 928 at this point
12 SwContentFrame::CalcLowers(SwLayoutFrame*, SwLayoutFrame const*, long, bool) (pLay=0x6dccbf0, pDontLeave=0x6ed6e30, nBottom=9223372036854775807, bSkipRowSpanCells=true) at tabfrm.cxx:1479
^ m_pLower -> 991 - SwRowFrame
13 lcl_RecalcRow(SwRowFrame*, long) (pRow=0x6dccbf0, nBottom=9223372036854775807) at tabfrm.cxx:1614
14 lcl_RecalcTable(SwTabFrame&, SwLayoutFrame*, SwLayNotify&) (rTab=..., pFirstRow=0x6dccbf0, rNotify=...) at tabfrm.cxx:1691
15 SwTabFrame::MakeAll(OutputDevice*) (this=0x6ed6e30) at tabfrm.cxx:2082
^ m_pFollow -> 905 - top-level SwTabFrame
16 SwTabFrame::MakeAll(OutputDevice*) (this=0x381d3e0) at tabfrm.cxx:2504
17 SwFrame::PrepareMake(OutputDevice*) (this=0x381d3e0) at calcmove.cxx:372
18 SwFrame::Calc(OutputDevice*) const (this=0x381d3e0) at trvlfrm.cxx:1790
^ 866 - top-level SwTabFrame
19 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7fff95aa3f20, pTab=0x381d3e0, bAddRect=true) at layact.cxx:1483
20 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6cfedc0, bAddRect=true) at layact.cxx:1375
21 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6e23fd0, bAddRect=true) at layact.cxx:1380
The first attempt was to add a TextFrameLockGuard around the
pFrame->MakeAll() call in PrepareMake(), with corresponding test in
SwTabFrame::MakeAll() ... but a similar problem still occurred, just now
on page 18 instead of page 12.
Another idea is to prevent PrepareMake() from formatting the
SwTableFrame's follow *again*; it was already formatted by
SwTabFrame::MakeAll() anyway, just before it calls pNxt->Calc().
With this, we get 23 pages for the bugdoc, same as before that commit:
(regression from 18765b9fa739337d2d891513f6e2fb7c3ce23b50)
Change-Id: I71e3f92b5f19b800626a008527fa75d08641e8de
Reviewed-on: https://gerrit.libreoffice.org/72799
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
This is some copypasta, apply the same fix.
Change-Id: I096594f6d54fef68e63c982c2963499d24af6d15
Reviewed-on: https://gerrit.libreoffice.org/72798
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
The problem is that with the change in SwFlowFrame::MoveBwd(), a
SwTextFrame in a table may move backwards during MakeAll(); if the next
frame of the moved frame, and the "this" frame in PrepareMake(), is a
SwTabFrame, then the pFrame->FindNext() will return not this SwTabFrame,
but the first SwTextFrame *inside* the SwTabFrame - hence the iteration
will never meet the "pFrame == this" termination condition and the
SwTabFrame remains unformatted; this warning is printed:
warn:legacy.osl:6874:6874:sw/source/core/layout/calcmove.cxx:296: :-( Layout unstable (this not found).
(regression from 18765b9fa739337d2d891513f6e2fb7c3ce23b50)
Change-Id: I68207ba9cf68cd5abe51d647cb757176261eda40
Reviewed-on: https://gerrit.libreoffice.org/72797
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I898fb0830a9f53da4a7917cb5900f082e3a9d6b7
Reviewed-on: https://gerrit.libreoffice.org/71944
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ic5cb575189984246365d8a1067e61ea84eaa5dce
Reviewed-on: https://gerrit.libreoffice.org/72768
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I67b76b65105e5020ea396ab68d41999c80368c41
Reviewed-on: https://gerrit.libreoffice.org/72812
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Change-Id: I6d44335ab51c92dc605ee341efaaa4bf6f7bd42f
Reviewed-on: https://gerrit.libreoffice.org/72587
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I23a6d485ee1ca0bc3801bcc1a6d748b8ed2b490c
Reviewed-on: https://gerrit.libreoffice.org/72634
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I677c3b184e225c3bac1c56efd5ea46aaa2497d69
Reviewed-on: https://gerrit.libreoffice.org/72810
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Property "PickListEntry" is available since LO 5.1 but not
mentioned in css.document.MediaDescriptor.
original change has been committed with tdf#95095.
Change-Id: I684e4c76f79c9646af3cac9670790d2b2c3eca97
Reviewed-on: https://gerrit.libreoffice.org/72553
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This is for COLEAT's internal use.
Change-Id: If1ac2a5b251129e4431d3c0bde82529d6bdc7ccc
Reviewed-on: https://gerrit.libreoffice.org/72809
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
The page handling implementation is a little bit tricky, because
the elemnt list is not handled like a grid but a list. Normally
one would keep the horizontal cell and just scroll vertically.
Instead this implements a kind of circle.
Vertical offset is consistet, so you have the same amount of
steps for up and down, but up runs left and down runs right.
Change-Id: I296a46e98f7e00a59fd0a0ba358c981b49ac86cd
Reviewed-on: https://gerrit.libreoffice.org/72793
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This adds arrows + home + end key navigation.
The grid is handled like a list. For convenience Left + Up
and Right + Down keys work in the same way.
Change-Id: I757184e5161f2c7ac9b241294a5edc304c882497
Reviewed-on: https://gerrit.libreoffice.org/72792
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Just implements Move the same way then Resize. More importantly
the patch correctly resets the Thumb and Page rectangles to
position (0,0) instead of just Empty, which ImplCalc is based on.
Otherwise this results in broken scroll bars, when the StarMath
elements window is docked in in the bottom or top area and
switches the scrolling orientation on undock.
Change-Id: I32b0507cdd6551cc7f42655a730faf8ef25b747b
Reviewed-on: https://gerrit.libreoffice.org/72794
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Switches the ScrollBar to horizontal in vertical mode and
adapts the scrolling.
Change-Id: I35370d74175ccd1f117b17f7d7ffa25119f2e612
Reviewed-on: https://gerrit.libreoffice.org/72791
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|