- 06 May, 2019 1 kayıt (commit)
-
-
Aron Budea yazdı
Change-Id: I7f8695789e1223df7bbb235fa6081ed91502ab99 Reviewed-on: https://gerrit.libreoffice.org/71852Reviewed-by:
Andras Timar <andras.timar@collabora.com> Tested-by:
-
- 03 May, 2019 9 kayıt (commit)
-
-
Tamás Zolnai yazdı
Otherwise it can happen that the file is locked by someone else during the saving method is running. I just extended the scope of the existing DisableUnlockWebDAV() calls a bit. In case of webdav it does not cause an issue to avoid unlocking the file before locking it again with an other SfxMedium. Change-Id: I6ac4e3326c63c9e184a7710ce8994cac1ed79449 Reviewed-on: https://gerrit.libreoffice.org/71484 Tested-by: Jenkins Reviewed-by:
Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit fdab1536) Reviewed-on: https://gerrit.libreoffice.org/71512Reviewed-by:
-
Andras Timar yazdı
Change-Id: Id386575029edf5a75f91b6831bbc7fe49741c06e
-
Michael Stahl yazdı
Fixes CVE-2019-7317. Change-Id: I3374f5cbd6552e2c1569d63ee680d0c1d9389621 Reviewed-on: https://gerrit.libreoffice.org/71663 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit e2abbc00)
-
Mike Kaganski yazdı
Change-Id: Id9f8f07bfdb1060f0c3d7ed6f8526a6bfdd84eb4 Reviewed-on: https://gerrit.libreoffice.org/71687 Tested-by: Jenkins Reviewed-by:
Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/71696Tested-by:
-
Muhammet Kara yazdı
During redaction of Calc sheets Change-Id: If2a4f71c77a687a74b8f823152b76d2a7e2e21da Reviewed-on: https://gerrit.libreoffice.org/71658Reviewed-by:
Muhammet Kara <muhammet.kara@collabora.com> Reviewed-by:
-
Henry Castro yazdı
Change-Id: I1893d52df505bc43428c37a624ca05c569ba1bc0 Reviewed-on: https://gerrit.libreoffice.org/70958 Tested-by: Jenkins Reviewed-by:
Henry Castro <hcastro@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/71369Reviewed-by:
Jan Holesovsky <kendy@collabora.com> Tested-by:
-
Mike Kaganski yazdı
... so that 2017-07-10T09:11:02.999999... becomes 2017-07-10T09:11:03, not 2017-07-10T09:11:02. The latter created duplicated items in pivot table cache previously. TODO: check what to do if the times are actually different by 100 ns? What Excel does then? Should we increase cache item precision? Change-Id: I622d1c784ee9fddf6b387bec2d8af87bae5668ba Reviewed-on: https://gerrit.libreoffice.org/71610 Tested-by: Jenkins Reviewed-by:
-
Mike Kaganski yazdı
Change-Id: Id727f10763bc5017eeb3e267b425d6013786d6a2 Reviewed-on: https://gerrit.libreoffice.org/71585 Tested-by: Jenkins Reviewed-by:
-
Muhammet Kara yazdı
Now that we have redaction enabled for Impress, after commit 33e840896a69a66c44e74beb995d558735fb84ad, let's sync the Impress Tools menu with Writer and Calc. Cherry-picked from commit f1c27ccc Change-Id: I1af03f6aa2043a70779a3b783045c69adc8641a3 Reviewed-on: https://gerrit.libreoffice.org/71508Reviewed-by:
-
- 25 Nis, 2019 10 kayıt (commit)
-
-
Henry Castro yazdı
Change-Id: I91fbfd97da0c4ad1ad90710ab781c71ca99367e5 Reviewed-on: https://gerrit.libreoffice.org/70609 Tested-by: Jenkins Reviewed-by:
-
Tamas Bunth yazdı
so gcc 4.8 would be happy about it. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480 Change-Id: I7e696758c5598b9e64947bc9b1606c653becddce Reviewed-on: https://gerrit.libreoffice.org/71294Reviewed-by:
-
Jan Holesovsky yazdı
According to my testing, this makes no difference and the moving of slides and multiple selection behaves the same way with or without this. So let's return to not activating the SlideSorterBar, because otherwise we are doing a lot of pixel bashing behind the scenes unnecessarily. Having said that, if we want to activate it at some stage, it is better to do something like the following (+ remove the explicit LOK-only if's from svtools/source/config/slidesorterbaropt.cxx): SvtSlideSorterBarOptions().SetVisibleImpressView(true); instead (and potentially we can also make it floating not to occupy the space in the main view by GetWindow()->SetFloatingMode(true); in the LOK case in sd/source/ui/dlg/PaneChildWindows.cxxi). Change-Id: I86b23b484674ad4c6a75246ee6186ad9b828931f Reviewed-on: https://gerrit.libreoffice.org/71271Reviewed-by:
Ashod Nakashian <ashnakash@gmail.com> Tested-by:
-
Jan Holesovsky yazdı
This shouldn't be necessary after the patch that removes the .uno:LeftPaneImpress and revert of the unit test changs. This reverts commit 23b03b5e. Change-Id: Ie056d66b1d88c317e1b44ebe290313c307d807ae Reviewed-on: https://gerrit.libreoffice.org/71273Reviewed-by:
-
Jan Holesovsky yazdı
At the moment, the commit that was supposed to fix the unit tests is actually breaking them for me, so let's revert. This reverts commit 72da60a4. Change-Id: I8ea636985de12ea19ad32a6064ece2d90589b7f9 Reviewed-on: https://gerrit.libreoffice.org/71272Reviewed-by:
-
Henry Castro yazdı
Rejecting paragraph formatting is not implemented yet. "Reject All" command is affected because the changes were not removed Change-Id: Ic4af1def97025643ecbc5cf0752cd06d9b94c74a Reviewed-on: https://gerrit.libreoffice.org/69865 Tested-by: Jenkins Reviewed-by:
-
Henry Castro yazdı
horizontal / vertical splits In the tiled rendering case the horizontal / vertical splits were not implemented, so the leftmost visible column is 0. So preserve horizontal / vertical splits when saving the document Change-Id: I15b6f009910e51fdaf475de5aac1ebded16c1956 Reviewed-on: https://gerrit.libreoffice.org/69926 Tested-by: Jenkins Reviewed-by:
-
Andras Timar yazdı
Change-Id: I1c7e1ea5b3ba5fa8b6969081b0df4eba48af327c
-
Michael Meeks yazdı
NB. outside of the often contended SolarMutexGuard. Change-Id: Ieb651e2ed4349e692010a7588721f461af7d2b5b Reviewed-on: https://gerrit.libreoffice.org/70848 Tested-by: Jenkins Reviewed-by:
Michael Meeks <michael.meeks@collabora.com>
-
Michael Meeks yazdı
Change-Id: Ie57c34eff1d917fada4e10e4b88b27adf8a34d1a Reviewed-on: https://gerrit.libreoffice.org/70788 Tested-by: Jenkins Reviewed-by:
-
- 24 Nis, 2019 10 kayıt (commit)
-
-
Andras Timar yazdı
Change-Id: I5ff8d4f1a9191aec082cacafb571e3171f464550
-
Eike Rathke yazdı
Change-Id: I9a497b9d9ae09c8764f62549a60c8a2a952bc9e9 Reviewed-on: https://gerrit.libreoffice.org/61822Reviewed-by:
Eike Rathke <erack@redhat.com> Tested-by: Jenkins
-
Eike Rathke yazdı
So listeners can be re-established for remaining grouped cells if top cell is deleted (which ends listening and probably was the cause to exclude them here). Change-Id: Ic91b74c65013452d56b5cfbc132722c4314743c8 Reviewed-on: https://gerrit.libreoffice.org/61808Reviewed-by:
-
Eike Rathke yazdı
This is a combination of 4 commits. Add unit tests for tdf#123736 and related unshared/regrouped listening Reviewed-on: https://gerrit.libreoffice.org/69372 Tested-by: Jenkins Reviewed-by:
Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
-
Eike Rathke yazdı
This is a combination of 7 commits. Resolves: tdf#123714 tdf#123736 all split formula groups; tdf#120013 related Add all split shared formula groups to regrouping and mark for listening, even if the references had not be to adjusted. This partly also resolves tdf#120013 but there's more to that, a remaining partial group is not updated. Reviewed-on: https://gerrit.libreoffice.org/68951Reviewed-by:
Dennis Francis <dennis.francis@collabora.com> Reviewed-by:
Katarina Behrens <Katarina.Behrens@cib.de>
-
Michael Meeks yazdı
Change-Id: I42a773e2d5b8e4deeafa8eeb2785913db36a47d7 Reviewed-on: https://gerrit.libreoffice.org/70688 Tested-by: Jenkins Reviewed-by:
Tor Lillqvist <tml@collabora.com> Tested-by:
-
Tamas Bunth yazdı
Change-Id: I54c1f438a755267db0896637c79f915de9113f83 Reviewed-on: https://gerrit.libreoffice.org/71246Reviewed-by:
-
Tor Lillqvist yazdı
(I know Swedish, this is not guesswork, there are no orthography differences.) Change-Id: I6f652f01dc95aa3a89fec1964c2a49109eb5e30b
-
Tor Lillqvist yazdı
On macOS, the system says it has a generic "de" dictionary. But on iOS, it says it is specificaly "de_DE". Assume it is good enough for the other German variants, too, for now. Change-Id: I745cc02c1ffa774dbcbfdc1d775ce358957f04f8
-
Mike Kaganski yazdı
For some reason, we have never exported the default column width to XLSX, although we have such export for XLS. This led to bugs like tdf#100946. Workarounds applied to those bugs have made LO to export columns which shouldn't have been exported, abusing "customWidth" attribute in XclExpColinfo::XclExpColinfo depending on if the column has size different from an app-global default; after that, sheet-local default was determined, and then columns which have mbCustomWidth set (i.e., different from app default), as well as those different from sheet-local default, were stored. Effectively, the hack had disabled the removal of defaults from maColInfos in XclExpColinfoBuffer::Finalize. We even had unit tests explicitly testing that we export those columns that Excel skips. The effect of that is not only unnecessary data in the file; the data was actually wrong (customWidth actually means that the width was edited manually by user, even if equal to the default, thus changing Excel handling of the column); and also Calc initializes all columns to the right of last used column for such a file. Only in case when app-global default happened to match sheet-local one, columns would have properties allowing them to be removed from maColInfos in the end of XclExpColinfoBuffer::Finalize, which still resulted in problems similar to the workarounded one. This patch implements proper export of the default column width to XLSX, thus partially reverting changes made for tdf#100946 in commit 40d892a2. Actually, our export to XLSX does not depend on the 5-pixel correction (see ECMA-376-1:2016 18.3.1.81), since the exported default depends only on most-used column width. XclExpDefcolwidth implementation was edited to only take the correction into account when exporting to XLS (to keep status quo; it's clear that XLS widths export and import implementation is incorrect: some empirical formula is used in XclTools::GetXclDefColWidthCorrection, that was introduced in commit 555d7029 for i#3006, that doesn't match any documentation, and changes widths of columns in exported XLS - something to be fixed independently). Change-Id: I227aca17e56247cbb839444717066a898987c4f1 Reviewed-on: https://gerrit.libreoffice.org/71132Reviewed-by:
-
- 23 Nis, 2019 4 kayıt (commit)
-
-
Miklos Vajna yazdı
Regression from commit 961ba62d (tdf#123032 sw, AddVerticalFrameOffsets: fix shape pos after mouse move, 2019-02-07), the vertical position of the bugdoc was too large, and turns out Word only works with vertical offsets if there is already a horizontal offset. For example open tdf98987.docx in Word, remove the left square shape, notice how the other square shape jumps up due to no longer working with a vertical offset (while the doc model vertical position of the shape is unchanged). Change our layout, so that in case the AddVerticalFrameOffsets compatibility flag is on (which was added to emulate Word's behavior), we also consider the horizontal offset before setting the vertical offset. Also improve the SwUiWriterTest2::testTdf122942() test that asserted doc model positions, which are now different (needed so that at the end the layout position visible to the user is unchanged). (cherry picked from commit 27894be9) Conflicts: sw/qa/extras/layout/layout.cxx sw/qa/extras/uiwriter/uiwriter2.cxx Change-Id: I8ac451efbacefdd3578b3a578260e7b2060c16a6 Reviewed-on: https://gerrit.libreoffice.org/71128Reviewed-by:
Aron Budea <aron.budea@collabora.com> Tested-by:
-
Miklos Vajna yazdı
Regression from commit 50223ea6 (tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31), the problem was that vertical position of the shape was wrong after mouse move, even if we attempted to take fly frames of the paragraph into account. (Similar situation is when saving and loading the file; which is much easier to test.) Fly frames are created as the text frames is formatted, and then SwTextFrame::CalcBaseOfstForFly() can calculate the vertical offset correctly. But in the "move with mouse" case SwToContentAnchoredObjectPosition::CalcPosition() was invoked by the time the old flys of the text frame were already removed, but the new ones were not yet added. Solve the problem by formatting the text frame from SwAnchoredDrawObject::MakeObjPosAnchoredAtPara() (if any of its validity flags are set to false) -- this is expected to be safe, as the object formatter is invoked by SwLayAction::FormatContent(), i.e. there is no recursive SwFrame::Calc() call here. (cherry picked from commit 961ba62d) Change-Id: I95851874e3da3f50f304421537c6743e04bdfc7b Reviewed-on: https://gerrit.libreoffice.org/71127Reviewed-by:
-
Miklos Vajna yazdı
Regression from commit 50223ea6 (tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31), SwFEShell::ImpEndCreate() was not adapted to call SwTextFrame::GetBaseVertOffsetForFly() when determining the vertical position of the inserted shape. The call can be unconditional, the returned value is already 0 when the DocumentSettingId::ADD_VERTICAL_FLY_OFFSETS compat setting is false. (cherry picked from commit 4218caf1) Conflicts: sw/qa/extras/uiwriter/uiwriter2.cxx Change-Id: Iec6af5a6d1ff3466e08377853cc8ca84f33a76d1 Reviewed-on: https://gerrit.libreoffice.org/71126Reviewed-by:
-
Ashod Nakashian yazdı
Change-Id: Ib736800544b9669e3708da0c01370af22cdf3e97 Reviewed-on: https://gerrit.libreoffice.org/69617Reviewed-by:
-
- 22 Nis, 2019 3 kayıt (commit)
-
-
Mike Kaganski yazdı
The name attribute of dataField element was already read in PivotTable::importDataField; and then it was ignored in PivotTableField::convertDataField. ScDataPilotFieldObj had no handler for name in its ScDataPilotFieldObj::[gs]etPropertyValue, although it has [gs]etName for that - so this change puts pieces together to allow to use the imported name correctly. Reviewed-on: https://gerrit.libreoffice.org/71068 Tested-by: Jenkins Reviewed-by:
-
Mike Kaganski yazdı
Otherwise, the empty string is used by Excel, so the field arrives unnamed, disappearing from pivot table's cells upon refresh, etc. Change-Id: I2e0f9fad2d766829f2b06425bec24ff182e3a869 Reviewed-on: https://gerrit.libreoffice.org/71065 Tested-by: Jenkins Reviewed-by:
-
Tomaž Vajngerl yazdı
Previously faux bold was drawn with setting a dictionary key kCTStrokeWidthAttributeName and a value of the stroke width. This stopped working because we don't use attributedString for drawing anymore but we always use CTFontDrawGlyphs and draw the glyphs, which doesn't have a way to set this attributes. It took me a while to find a workaround (thanks to Apple's great documentation), where we switch text drawing to fill and stroke, and after that we can modify the stroke by changing the line width. Reviewed-on: https://gerrit.libreoffice.org/71012 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit eb560651) Change-Id: I594fcb9c796a9c04ea8234a9938ca2f719706199
-
- 21 Nis, 2019 1 kayıt (commit)
-
-
Mike Kaganski yazdı
On Windows, gpgme expects gpgme-w32spawn.exe to be in the same directory as the current process executable. This assumption might be wrong, e.g., for bundled python, which is in instdir/program/python-core-x.y.z/bin, while gpgme-w32spawn.exe is in instdir/program. In this case, if an operation in a python script requires initializing gpgme, it will be interrupted by a modal warning box telling that gpgme-w32spawn.exe was not found. If we can't find gpgme-w32spawn.exe in the current executable location, then try to find the spawn executable, and inform gpgme about actual location using gpgme_set_global_flag. Change-Id: Ie30a0d4a6666767e8c54f1bdc67b67570d6ea47a Reviewed-on: https://gerrit.libreoffice.org/71014 Tested-by: Jenkins Reviewed-by:
-
- 20 Nis, 2019 2 kayıt (commit)
-
-
Mike Kaganski yazdı
Also provide a default pivot table style for those tables that don't have a style info. Let's use the style settings that Excel uses. Change-Id: I8006a33a0aa0e92629f7db0a9c24a6ff52d17945 Reviewed-on: https://gerrit.libreoffice.org/70933 Tested-by: Jenkins Reviewed-by:
-
Tamás Zolnai yazdı
Handle %7c with small letters. Make sure that the output parameter's content is not affected by decoding. Change-Id: Ie3faad2461815497c0edfb04a589fc57aeb7d66b Reviewed-on: https://gerrit.libreoffice.org/70873 Tested-by: Jenkins Reviewed-by:
-
