- 22 May, 2019 31 kayıt (commit)
-
-
Xisco Fauli yazdı
Change-Id: I2080f3c04a04cea626d4969b59e54612cbefe03b Reviewed-on: https://gerrit.libreoffice.org/72780Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by:
Xisco Faulí <xiscofauli@libreoffice.org>
-
Ilmari Lauhakangas yazdı
Change-Id: I3ea246c84bb81e4eca9fe569edb957bed3c788ee Reviewed-on: https://gerrit.libreoffice.org/72674 Tested-by: Jenkins Reviewed-by:
Luboš Luňák <l.lunak@collabora.com>
-
Stephan Bergmann yazdı
...following up on 1453c2c8 "prefer vector::data to &vector[0]" Change-Id: I7c113747d92d144a521d49b89384dd8bf1215c01 Reviewed-on: https://gerrit.libreoffice.org/72765 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com>
-
Stephan Bergmann yazdı
...to avoid the upcoming loplugin:data asking to replace just each initial &aAttrs[0] with aAttrs.begin() and leave the remaining &aAttrs[N] alone, which would make the results look odd. Change-Id: I7d5c76e9d4fc6c7fa13cb28fca5ea65ea2d0f77e Reviewed-on: https://gerrit.libreoffice.org/72764 Tested-by: Jenkins Reviewed-by:
-
Stephan Bergmann yazdı
...to avoid the upcoming loplugin:data asking to replace just the initial &aStrs[0] with aStrs.begin() and leave the rest alone, which would make the result look odd. Change-Id: I37a86fc494c47afc56de041f3d803356fb97317d Reviewed-on: https://gerrit.libreoffice.org/72762 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: If7a5e779716e9423e94c22d11fc0f029fb89401f Reviewed-on: https://gerrit.libreoffice.org/72754 Tested-by: Jenkins Reviewed-by:
Julien Nabet <serval2412@yahoo.fr>
-
Julien Nabet yazdı
Regression from https://cgit.freedesktop.org/libreoffice/core/commit/?id=3208fcb3a36d75d6290d9c548430682f153b09db Change-Id: I8f85f0a5838df87671ecb9bdb5751b7ec43c09ea Reviewed-on: https://gerrit.libreoffice.org/72701 Tested-by: Jenkins Reviewed-by:
Lionel Elie Mamane <lionel@mamane.lu>
-
Michael Stahl yazdı
Fixes CVE-2019-5435. It looks like this is not a problem on 32-bit Windows because fortunately we don't use /LARGEADDRESSAWARE flag to set IMAGE_FILE_LARGE_ADDRESS_AWARE... but on 32-bit Linux the user-space VM is 3GB so an exploit might be possible. Apparently there's no code in LO that uses the CURLU_URLENCODE flag. The other one, CVE-2019-5436, doesn't matter because we disable tftp. Change-Id: I0d4f087befa5a3c4fb21ec36761dad68932425d9 Reviewed-on: https://gerrit.libreoffice.org/72732 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de>
-
Stephan Bergmann yazdı
...which causes asserts to fire since <https://github.com/llvm/llvm-project/ commit/04323c24a1ac9464471331d9f6499d3cb95d1ccd> "Added an assertion to constant evaluation enty points that prohibits …" Change-Id: Iafbf1cea85d15a38a71275d4cea8303bab500f6a Reviewed-on: https://gerrit.libreoffice.org/72723 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
It doesn't correctly make a dependency on the .gch or anything the .gch is made from, so there would be stale cache hits even if anything included from the .gch changed. Disable CCACHE_DEPEND. https://github.com/ccache/ccache/pull/427 Change-Id: I6929ff6ec1f1e50498033cdf95b56c94522166eb Reviewed-on: https://gerrit.libreoffice.org/72704 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
With just -include a.hxx ccache checks only for presence of a.hxx.gch and it doesn't search the path given by -I, so it didn't detect the usage of the .gch and thus didn't include it in the checksum, possibly leading to false positives. Icecream similarly doesn't search paths given by -I and may fail to properly handle the .gch usage. Change-Id: I40ba2d5089e77cd5e8da670c7e030f9e90ebc8ac Reviewed-on: https://gerrit.libreoffice.org/72703 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
Enable the gtk3_kde5 and kde5 VCL plugins as discussed in ESC all of 2019-05-02. Also drop the "--disable-gtk3" switch so gtk3 is built as well (which is enabled by default). Change-Id: I65230255f8db6a7de992c6f5e9f9892a72436349 Reviewed-on: https://gerrit.libreoffice.org/71865 Tested-by: Jenkins Reviewed-by:
Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
-
Luboš Luňák yazdı
There's pretty much the same code in CanvasHelper::fillTexturedPolyPolygon() that has received various fixes over the time, but this code not, so fix it as well. Change-Id: I7293d4d67dff2d5276928bb3ab25adfb883ce3ca Reviewed-on: https://gerrit.libreoffice.org/72700 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: If99c008f40c20ba97b0abd1203b7e89378cd7095 Reviewed-on: https://gerrit.libreoffice.org/72731 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
See <https://gerrit.libreoffice.org/#/c/67754/3> for discussion, the stability of this test has to be improved before it can be enabled again. Change-Id: Iae7d16c7a6c3659de132e2d64ca43865081b3c9b Reviewed-on: https://gerrit.libreoffice.org/72724Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
-
Caolán McNamara yazdı
Change-Id: I8d5bb318674311b1e21c6fdf487d69609af344a5 Reviewed-on: https://gerrit.libreoffice.org/72686 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Noel Grandin yazdı
The problem here is that we never actually hit the maExportGraphics cache in SvXMLGraphicHelper, even though we are passing the same image down repeatedly. There are two bugs here: (1) BitmapEx::operator== does not return true if we instantiate 2 Graphic objects from the same XGraphic, so change it to use the more expensive operator==. To mitigate the cost, move the expensive checks to the bottom of the method. (2) in order to use an object in std::unordered_map, the object must implement an equality function and a hash function. If two objects are equal THEY MUST have the same hash value. Using the Impl* as the hash value does not satisfy that condition, so rather use the checksum, which does. After these fixes, the save time drops to less than a second. Also make the checksum method look more like the operator== method, and add a checksum calculation method for SVG data that more accurately reflects the underlying SVG data. Change-Id: I4ca0c7bee60b2efa6fe42301e582c7b278022b46 Reviewed-on: https://gerrit.libreoffice.org/72615 Tested-by: Jenkins Reviewed-by:
-
Gabor Kelemen yazdı
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ib7e1d0f7483aa8b5cab320278714f2d5f36fdbd9 Reviewed-on: https://gerrit.libreoffice.org/72534 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
Change-Id: I7e45e30f8e316c49d1fe2311baf82a5729905a3c Reviewed-on: https://gerrit.libreoffice.org/72702 Tested-by: Jenkins Reviewed-by:
-
Balazs Varga yazdı
by considering the axis direction. Note: Legend name order in left/right position was fixed in commit 40144617 Change-Id: Id5bd585a666c3bcf346af5317e9197e6460f932a Reviewed-on: https://gerrit.libreoffice.org/72670Reviewed-by:
László Németh <nemeth@numbertext.org> Tested-by:
-
László Németh yazdı
and endnotes by creating redline data for their anchors, too. Now footnote/endnote insertions are visible, and it's possible to reject them. Change-Id: I5cd3300c0d423b8c6803b7aeb848dcc103c3b565 Reviewed-on: https://gerrit.libreoffice.org/72680 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I3bb52201d523fd1c97315c99ce58e4473f971a12 Reviewed-on: https://gerrit.libreoffice.org/72699 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I8d0eb79c1848714c637d05064b6aae5140843c20 Reviewed-on: https://gerrit.libreoffice.org/72707 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I88e2a10836ae961764d899b8d74fd707a3e15b2c Reviewed-on: https://gerrit.libreoffice.org/72708 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I97909d9d6ece176f519318ebb53b4cdfeeba9146 Reviewed-on: https://gerrit.libreoffice.org/72709 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I257313aa1744f8c70ea9888cd19adde149c1ce64 Reviewed-on: https://gerrit.libreoffice.org/72716Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I09c624e4def7a0a3f0a753f9f325b4863dceac0e Reviewed-on: https://gerrit.libreoffice.org/72706 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: Ib28c9a3df6b6d6b6f65e2c9b0810655b963eb1ff Reviewed-on: https://gerrit.libreoffice.org/72711 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: Ibaafe29797523290f0fe17be7304c99a70752eda Reviewed-on: https://gerrit.libreoffice.org/72712 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I627d0d9899226eb39a19bde1ecf79f04ca26e633 Reviewed-on: https://gerrit.libreoffice.org/72717Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I69c3a6b6ca8d5a568ec7f052c742335dd50bda5b Reviewed-on: https://gerrit.libreoffice.org/72714 Tested-by: Jenkins Reviewed-by:
-
- 21 May, 2019 9 kayıt (commit)
-
-
Tomaž Vajngerl yazdı
The problem with latest macOS versions is that creating a graphic context with window (NSGraphicsContext graphicsContextWithWindow:) only works when actually drawing and otherwise it returns null. This caused problems before in AquaVrtualDevice, but we also use this when creating a device backing storage. This interestingly caused slowdowns and eventual crash, but the backtrace looked very misterious as it didn't crash because of a nullptr, but it halted all drawing commands and it crashed because of that. This changes the graphic context with a bitmap context, as it was already done in VirtualDevice and use that instead. The problem with a bitmap context is that we need to handle HiDPI scaling by ourselves now. LayerHolder was extended to store the scaling information of the layer (and its underlaying bitmap context) and provides methods that get the size of the layer in pixels or in scaling independent points (which is just size in pixels multiplied by the scaling factor). An known issue is that VirtualDevice also needs to take scaling into account, which it currently doesn't, so the text is still blurry on a HiDPI screen, but that was already true previously and is something that will be done in a different change. Change-Id: I8e10c518ecba285125746bd20525c4cb5ca67279 Reviewed-on: https://gerrit.libreoffice.org/72663 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com>
-
Tomaž Vajngerl yazdı
This adds the ability to define the spinbox orientation that has decrease and increase buttons on the right side and can be changed by adding "orientation="edit-decrease-increase" to the Spinbox "Entire" part in the widget definition. Change-Id: I3601a987a4abb8d998e9cd2d8973d794d3d66f9b Reviewed-on: https://gerrit.libreoffice.org/72662 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
This is similar to e8d5b8be (tdf#113714 vcl menu bar window: avoid flicker, 2019-05-20), except that was for the menu bar window, and this is for the floating window opening from that one. Change-Id: Ib24f4999ad3e8cbbecc058368e9d112e106e9178 Reviewed-on: https://gerrit.libreoffice.org/72688Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I2c4fcfee1ee9901297acebc11a7698633c3c21ef Reviewed-on: https://gerrit.libreoffice.org/72696Reviewed-by:
-
Miklos Vajna yazdı
Change-Id: I5987fcc04396e4e22640d6b09b52fa7b08460369 Reviewed-on: https://gerrit.libreoffice.org/72687Reviewed-by:
-
Mike Kaganski yazdı
Since the guard is only cleared optionally, most probably the code after the conditional block is expected to be guarded until the second clear. Change-Id: I913cb4bff42140da605a6f45414bece419f4a4c8 Reviewed-on: https://gerrit.libreoffice.org/72689 Tested-by: Jenkins Reviewed-by:
Mike Kaganski <mike.kaganski@collabora.com>
-
Tamás Zolnai yazdı
Change-Id: I1be6e4cf52ccd385d59f85d9d5fa5b8a47caf4f1 Reviewed-on: https://gerrit.libreoffice.org/72697Reviewed-by:
Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by:
-
Tamás Zolnai yazdı
Revert the commit caused this regression: 0fc41c53 The original issue does not come back with reverting this commit. Change-Id: I666c4f92e3b70b416ec6da7a704298d207451649 Reviewed-on: https://gerrit.libreoffice.org/72679 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I5f062a2d3260110b1108dd28c8a536652416acf2 Reviewed-on: https://gerrit.libreoffice.org/72692Reviewed-by:
-
