- 08 Şub, 2019 14 kayıt (commit)
-
-
Gabor Kelemen yazdı
Since it is now possible to use C++14, it's time to replace the temporary solution with the standard one Change-Id: Ib3201f865d43f372007cdf381c7e244e9cbeae26 Reviewed-on: https://gerrit.libreoffice.org/67474 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com>
-
Caolán McNamara yazdı
Change-Id: I579d6d555b0f01df22e6f97912712a9ec2bf69a6 Reviewed-on: https://gerrit.libreoffice.org/67532 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Caolán McNamara yazdı
Change-Id: Ib56b22743ef6b9eb849291f9d8eba02450e3fc68 Reviewed-on: https://gerrit.libreoffice.org/67531 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
rather than have version specific behaviour Change-Id: I75866a45859f93d290f79c63b586fee2a19816f3 Reviewed-on: https://gerrit.libreoffice.org/67529 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: Ib685ea89b31c1f000bc2276e3362ba059f997422 Reviewed-on: https://gerrit.libreoffice.org/67521 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: Ib58ac1c7171331eac543eba7b5f7bae8fa04ae4d Reviewed-on: https://gerrit.libreoffice.org/67524 Tested-by: Jenkins Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
Noel Grandin yazdı
Change-Id: I8dee6245cfa1f7998591b31a3752bbbae13f499d Reviewed-on: https://gerrit.libreoffice.org/67527 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I9ef57a2e9aaf298f4cfd029aa9b8143871b1bc21 Reviewed-on: https://gerrit.libreoffice.org/67526 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: Ie4e27466c4258c6f774a3ebb82ec3a88c28fd753 Reviewed-on: https://gerrit.libreoffice.org/67525 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
Change-Id: I58c689f5a1b034f64687031e24b82a3ac56e4bae Reviewed-on: https://gerrit.libreoffice.org/67519 Tested-by: Jenkins Reviewed-by:
-
Stephan Bergmann yazdı
* Update helpcontent2 from branch 'master' - Fix "Error: Duplicated entry. ID = par_id3146919" ...after 00c5a418955574905aed5137c43ce2219b50e6f9 "Minor color and padding tweaks; some styling for TOC" Change-Id: I4340e2e52a5cbd7627364157aeb9eec17bc96cb4 -
andreas kainz yazdı
Change-Id: I3ab1f7a5ec55d3f7fd8886d3578a9437f4ce03c1 Reviewed-on: https://gerrit.libreoffice.org/67522 Tested-by: Jenkins Reviewed-by:
andreas_kainz <kainz.a@gmail.com>
-
Andrea Gelmini yazdı
Change-Id: I58c8a755584c41f070a04fafe38720286b726d63 Reviewed-on: https://gerrit.libreoffice.org/67523 Tested-by: Jenkins Reviewed-by:
Julien Nabet <serval2412@yahoo.fr>
-
Adolfo Jayme Barrientos yazdı
* Update helpcontent2 from branch 'master' - Minor color and padding tweaks; some styling for TOC Just to fix the most egregious issues in content paragraphs. Some day I will actually have the energy to systematize everything into a cohesive set of spacing and padding values. Change-Id: I6d5d36e96d9c9a133d61b233413ebd17d8189d33
-
- 07 Şub, 2019 26 kayıt (commit)
-
-
Mark yazdı
* Update helpcontent2 from branch 'master' - tdf#107930 - Help needs to be corrected and amended for Recalculation changed test in 06080000.xhp Change-Id: I4cc8a0a04517306e5196aa79c607e624b488a56f Reviewed-on: https://gerrit.libreoffice.org/67518 Tested-by: Jenkins Reviewed-by:Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
Caolán McNamara yazdı
Change-Id: If2029eaae250ed3ee4ab56dae7ec67c2deba3ab8 Reviewed-on: https://gerrit.libreoffice.org/67515 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I70cabe6c028cdfae06d0f677979937f18249917a Reviewed-on: https://gerrit.libreoffice.org/67513 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
of an embedded XLSX OLE object, instead of showing always the first sheet. Change-Id: I583a17dc8a3cd06ee15fbbb950328f0b9b164a63 Reviewed-on: https://gerrit.libreoffice.org/67516 Tested-by: Jenkins Reviewed-by:
László Németh <nemeth@numbertext.org>
-
Zdeněk Crhonek yazdı
Change-Id: I7d8e43d744361ff0301ce387318cc91925810e69 Reviewed-on: https://gerrit.libreoffice.org/67514 Tested-by: Jenkins Reviewed-by:
Zdenek Crhonek <zcrhonek@gmail.com>
-
Miklos Vajna yazdı
The markup is: <dgm:if name="Name6" axis="ch ch" ptType="node node" st="1 1" cnt="1 0" func="cnt" op="gte" val="1"> Where PowerPoint evaluated the condition to true, but Impress evaluated to false. This means that the undocumented relation between the child lists is "OR" (not "AND"). Also, our code assumed that "node" has to be a data node (not presentation node), but it seems the only way this condition can be true if presentation children is also counted. (The presentation node in question is not a presentation of anything.) Change-Id: I094b44351aeb8058cd50753f46fcdac7a88b35cd Reviewed-on: https://gerrit.libreoffice.org/67510Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I03dfa49f4a8b269408d9037feb9c5c984f6c3c52 Reviewed-on: https://gerrit.libreoffice.org/67511 Tested-by: Jenkins Reviewed-by:
-
Stephan Bergmann yazdı
Change-Id: I82b8c49fcbbec161bf968573e28992fa5737b45b Reviewed-on: https://gerrit.libreoffice.org/67508 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com>
-
Stephan Bergmann yazdı
...which happens when GetParent()->GetOutputSizePixel().Width() is zero (as seen, e.g., during JunitTest_forms_unoapi_2). It is assigned to sal_uInt16 nX further down, which then causes failure with Clang's -fsanitize=implicit-signed- integer-truncation. And when the parent size is apparently too small (zero) there is probably no value in operating with a value less than zero here---there won't be a reasonable layout of controls anyway. Change-Id: Ic1fa75f94a9a2878c60fca4cb03e4fbf6f9fda98 Reviewed-on: https://gerrit.libreoffice.org/67507 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
regression from commit commit 1b7bcaa7 use unique_ptr in svx Change-Id: Ie3ced1f13ae3d35205174a02d6cbc2c19a171871 Reviewed-on: https://gerrit.libreoffice.org/67498 Tested-by: Jenkins Reviewed-by: -
Caolán McNamara yazdı
Change-Id: I40df84d476b50f245c6d0849269006300e93f54a Reviewed-on: https://gerrit.libreoffice.org/67497 Tested-by: Jenkins Reviewed-by:
-
Stephan Bergmann yazdı
Change-Id: I19b0cc48b18ddda5bd09c88f03565e9b73ed776a Reviewed-on: https://gerrit.libreoffice.org/67495 Tested-by: Jenkins Reviewed-by:
-
Stephan Bergmann yazdı
Change-Id: I1999113b5c5ad533dc37ffd9adb9dfe346d5d749 Reviewed-on: https://gerrit.libreoffice.org/67493 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
this reverts commit 3c4cfa20 Date: Mon Nov 26 12:51:05 2007 +0000 INTEGRATION: CWS fwk72 (1.195.14); FILE MERGED 2007/09/10 14:55:01 mav 1.195.14.1: #i81437# do not allow to export to the file the document is based on Change-Id: I8bf1524a8cc2d6d1911bdd228f33f1b7723e1d6e Reviewed-on: https://gerrit.libreoffice.org/67491 Tested-by: Jenkins Reviewed-by:
-
Muhammet Kara yazdı
Change-Id: I2310907071d2a8d63d78dbeb99022309870d5c34 Reviewed-on: https://gerrit.libreoffice.org/67489 Tested-by: Jenkins Reviewed-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. Change-Id: I95851874e3da3f50f304421537c6743e04bdfc7b Reviewed-on: https://gerrit.libreoffice.org/67490Reviewed-by:
-
Tor Lillqvist yazdı
Change-Id: I52d75427fe30945293f347e3f49d21bc2016edae
-
Tor Lillqvist yazdı
Change-Id: I134101d1be5922051e34352331a49f5706030ff2
-
Caolán McNamara yazdı
dropping the cached scaled bitmap when the bitmap is accesed via BitmapAccessMode::Write for writing Change-Id: Ib6539522944838238bd699ec3531039d21dc0f8b Reviewed-on: https://gerrit.libreoffice.org/67459 Tested-by: Jenkins Reviewed-by:
-
Henry Castro yazdı
Change-Id: I3a1072e6ededbd0322c4b1dcd0ef4b16ace219d1 Reviewed-on: https://gerrit.libreoffice.org/67478Reviewed-by:
Jan Holesovsky <kendy@collabora.com> Tested-by:
-
Stephan Bergmann yazdı
On the one hand, SvxZoomSliderItem/SvxZoomSliderControl as used by SwView's SID_ATTR_ZOOMSLIDER support a range from MINZOOM (20) to MAXZOOM (600) (defined in sw/inc/view.hxx). Setting a zoom value outside that range for one causes the DBG_ASSERT "Looks like the zoom slider item is corrupted" in SvxZoomSliderControl::StateChanged (svx/source/stbctrls/zoomsliderctrl.cxx) to fire, and for another (when setting a too small value) tries to assign a negative value (which wraps around, and gets flagged by Clang's -fsanitize=implicit-signed-integer-truncation) to sal_uInt16 nCurrentZoom at nCurrentZoom = nCurrentZoom - mxImpl->mnMinZoom; in SvxZoomSliderControl::Zoom2Offset (svx/source/stbctrls/zoomsliderctrl.cxx). On the other hand, SwXViewSettings' support of css.text.ViewSettings' ZoomValue property allowed values in the range from 5 to 1000 (cf. SwXViewSettings::_setSingleValue in sw/source/uibase/uno/unomod.cxx), and some JunitTests actually set such values (10, 15) below the MINZOOM value of 20. The incompatible 5--1000 range was there ever since 7b0b5cdf "initial import", but looks rather random, so change it to match the 20--600 range instead. (And lets flag this as an [API CHANGE], to be on the safe side.) One of the JunitTests files that needed to be adapted, qadevOOo/tests/java/mod/_sw/SwAccessibleEndnoteView.java, oddly mentioned a zoom value of 130% in a comment while using the value 15 in the actual code. (And did so ever since the test code's introduction in 26ebdfc4 "NEW: initial version".) Changing the code to 130 would cause JunitTest_sw_unoapi_1 to fail in strange ways, with disposed UNO objects, while changing the code (and comment) to 21 appears to work. Go figure. Change-Id: Id944ffdce501448312e008436e7038bf2aec63ac Reviewed-on: https://gerrit.libreoffice.org/67427 Tested-by: Jenkins Reviewed-by:
Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Reviewed-by:
-
Gabor Kelemen yazdı
Since it is now possible to use C++14, it's time to replace the temporary solution with the standard one Change-Id: I871312c1077439377c67b76112f38b7019fa6fb1 Reviewed-on: https://gerrit.libreoffice.org/67376 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
Change-Id: I1d6a2b5d2b34dfd3356650a14cc853d00afbdda9 Reviewed-on: https://gerrit.libreoffice.org/67476 Tested-by: Jenkins Reviewed-by:
-
andreas kainz yazdı
Change-Id: I362673c0dc6f687a7b9232b985243534a17285ad Reviewed-on: https://gerrit.libreoffice.org/67479 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: If4e07d497ead58a2ff58b5fdedd282b8784be421 Reviewed-on: https://gerrit.libreoffice.org/67435 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I9b57e73303cb12e818cd761878d0c11c38f4cc3e Reviewed-on: https://gerrit.libreoffice.org/67481 Tested-by: Jenkins Reviewed-by:
-
