- 02 May, 2019 8 kayıt (commit)
-
-
Caolán McNamara yazdı
Change-Id: I8d3f7653b7e9b64a2f433b4ebfb8a0fef1522e93 Reviewed-on: https://gerrit.libreoffice.org/71637 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Caolán McNamara yazdı
Under gtk 3.24.8 dragging into the TreeView is not highlighting the entire rreeView widget, just the rectangle which has no entries in it. This looks ok when its empty, but not when it has some entries in it, and when the list is full, there is then no border highlight. So as a workaround highlight the parent container on drag start, and undo it on drag end, and trigger removal of the treeview's highlight effort. Change-Id: I37be1e53a9ad3c6b810b579f6e5699c45b7b8e2b Reviewed-on: https://gerrit.libreoffice.org/71624 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Arkadiy Illarionov yazdı
Similar to clang-tidy readability-container-size-empty Change-Id: I71e7af4ac3043d8d40922e99f8a4798f0993294c Reviewed-on: https://gerrit.libreoffice.org/71603 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Stephan Bergmann yazdı
(lexicographically, by Unicode code point values; to make it easier to add further entries) Change-Id: Icd5a58b6b65004ceb90f470ae58512d9f8ae57e7 Reviewed-on: https://gerrit.libreoffice.org/71571 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
-
Stephan Bergmann yazdı
...by storing the temporary HTML document in a location that can be accessed by the browser running outside the Flatpak sandbox. This reuses and extends the mechanism already in place for the new HTML-based help in Flatpak mode (see 72b936d7 "Enable --help=html for flatpak"). This fixes <https://github.com/flathub/org.libreoffice.LibreOffice/issues/85> "“Preview in Web Browser” does not work in Flatpak version". Change-Id: I5f73fd89139ffe6b8ab0dc501154b4f054a0ae5c Reviewed-on: https://gerrit.libreoffice.org/71570 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
-
László Németh yazdı
Localized range separators resulted broken XLSX export with duplicated built-in names. For example, XLSX export of a Format->Print range using Hungarian locale in LibO raised an error message in MSO, because the export contained the same range also with a bad semicolon: <definedName>Sheet1!$A:$A;Sheet1!$1:$1</definedName> <definedName>Sheet1!$A:$A,Sheet1!$1:$1</definedName> Change-Id: Iee6ff7c5f5952fc1e736cebfc290c64a851786ab Reviewed-on: https://gerrit.libreoffice.org/71538 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
-
Jens Carl yazdı
Move XReplaceDescriptor Java tests to C++ for ScCellSearchObj. Change-Id: Ica5042ce8b5eac3663a0fb5f66ae0a2830c89d93 Reviewed-on: https://gerrit.libreoffice.org/71645 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
-
Jens Carl yazdı
Move SearchDescriptor Java tests to C++ for ScCellSearchObj. Change-Id: I3c9ffbfc80c7fdc39d0e67fe8aae12605a8d04f5 Reviewed-on: https://gerrit.libreoffice.org/71644 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
-
- 01 May, 2019 24 kayıt (commit)
-
-
Jens Carl yazdı
Move XSearchDescriptor Java tests to C++ for ScCellSearchObj. Change-Id: I1ae50bb586fd742b7cc19f71bcae018ca42139e6 Reviewed-on: https://gerrit.libreoffice.org/71643 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
-
Andrea Gelmini yazdı
Change-Id: I20e6de52e8244ef118973671cd25fb9fc6f3e22f Reviewed-on: https://gerrit.libreoffice.org/71632Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
-
Andrea Gelmini yazdı
Change-Id: I56626f7df54c31847f150374dbb41ace274d5c2d Reviewed-on: https://gerrit.libreoffice.org/71634Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
-
Andrea Gelmini yazdı
Change-Id: I0def9e55b25aec0920e1a6aafb9f4c75ad6a06f7 Reviewed-on: https://gerrit.libreoffice.org/71635Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
-
Andrea Gelmini yazdı
Change-Id: I7dee823ce762e14fb1b96a7aa3ced2d64a66c82c Reviewed-on: https://gerrit.libreoffice.org/71636Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
-
Caolán McNamara yazdı
Change-Id: I1c3185530f7b892f78f71d2db8534aec07e73e57 Reviewed-on: https://gerrit.libreoffice.org/71623 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Caolán McNamara yazdı
Change-Id: Ia570417f6f7926dbce19944d91d4a9cb9814eb19 Reviewed-on: https://gerrit.libreoffice.org/71622Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Jens Carl yazdı
Change-Id: Id8f78e2b114945f2c2499739711db9223828314a Reviewed-on: https://gerrit.libreoffice.org/71609 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
-
Michael Meeks yazdı
The reasoning is somewhat complex: void Window::ImplInvalidateFrameRegion( const vcl::Region* pRegion, InvalidateFlags nFlags ) sets the mnPaintFlags on the mpWindowImpl - and then queues an idle paint. This paint in LOK mode does ~nothing - since all rendering is tiled, although amazingly it does emit eg. selection callbacks. However the paint flag - changes the behavior of Window::Update() to force a complete window invalidate. This happens, but only rarely - when a key-event manages to get into the mainloop before the idle paint handler arrives and does nothing (except clear the paint flags). So - don't do these big invalidations we don't need to in lok mode, unless it is for dialogs - which presumably Pranav wanted fixed by 625087b5. Change-Id: I88dda34b8d8bba9c89296d883ad9169fe49a7c5e Reviewed-on: https://gerrit.libreoffice.org/71395 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
-
Todor Balabanov yazdı
Change-Id: I6d204a7ba0fa19f4c318d1c70f5a0344e0640d6d Reviewed-on: https://gerrit.libreoffice.org/71620 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Todor Balabanov yazdı
Change-Id: Ia35e3bb3b4f0323c7fbfc54ae5064afdf2c3f381 Reviewed-on: https://gerrit.libreoffice.org/71539 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Todor Balabanov yazdı
Change-Id: I16149cabf75ec928d96975e4b98622df6951cefc Reviewed-on: https://gerrit.libreoffice.org/71519 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Caolán McNamara yazdı
Change-Id: I821ee682bf5b65774a609227811365b94ae2063e Reviewed-on: https://gerrit.libreoffice.org/71547 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Mike Kaganski yazdı
Previously, for an XML like this: <sharedItems> <d v="2017-07-10T09:11:02"/> <d v="2017-07-10T09:11:03"/> <m/> </sharedItems> the call like int pos = getXPathPosition(pDoc, "/x:sharedItems", "absent"); gave 3. That could result in mistakes, when a test would assert on position "3" for a child element which name is mistyped. I made such a mistake when creating a unit test trying to assert on a position of the last element, and writing its name as "x:m", like in rXPath itself; the return was 3, and I initially wrongly assumed that the return is 1-based (like in xpath bracketed expressions). rChildName made const OString&, for consistency with rXPath, or with rAttribute in getXPath: child name is just a part of a longer xpath. Change-Id: I7ba9c4466c75b1b10fce1ccf26ef3b56b4e11e87 Reviewed-on: https://gerrit.libreoffice.org/71614 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
-
andreas kainz yazdı
Change-Id: I90e103f1ded9671817b83ae4755c235acf4050f1 Reviewed-on: https://gerrit.libreoffice.org/71619 Tested-by: Jenkins Reviewed-by: andreas_kainz <kainz.a@gmail.com>
-
Zdeněk Crhonek yazdı
Change-Id: Id3f8a0e7b03e47d5f09e87320006fbed293e941f Reviewed-on: https://gerrit.libreoffice.org/71602 Tested-by: Jenkins Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>
-
Julien Nabet yazdı
Change-Id: I8a7be3738cd84699568ae2711367e49754401609 Reviewed-on: https://gerrit.libreoffice.org/71594 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
-
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 <mike.kaganski@collabora.com>
-
Jens Carl yazdı
Move XPropertSet Java tests to C++ for ScCellSearchObj. Change-Id: I46e55794fe0b205173c3b208ba84c90d70aa2de0 Reviewed-on: https://gerrit.libreoffice.org/71608 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
-
Andrea Gelmini yazdı
Change-Id: If5e6366e307349fa17ba450d330c1f57f9e05d30 Reviewed-on: https://gerrit.libreoffice.org/71611Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
-
Andrea Gelmini yazdı
Change-Id: Ia4889e796284e2159e88dddbdf5efa8ed8dfb864 Reviewed-on: https://gerrit.libreoffice.org/71613Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
-
Andrea Gelmini yazdı
Change-Id: I1c7c7c1fdbcf442e367fe3f61c1c6c9eeadc0a95 Reviewed-on: https://gerrit.libreoffice.org/71612Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
-
Noel Grandin yazdı
Just because this image is transparent, does not mean it is equal to the other image. Similarly, just because this image has transparency color, does not mean the other image has valid transparency color. Also move the cheaper mbAlpha check before the more expensive ShallowEquals check. there since commit 8ab086b6 Date: Mon Sep 18 16:07:07 2000 +0000 initial import Change-Id: I63033bc8e7fed991513a171e637768e826eafad9 Reviewed-on: https://gerrit.libreoffice.org/71572 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Julien Nabet yazdı
Change-Id: I4934240946b435e7b5b13c2623143f7741106efa Reviewed-on: https://gerrit.libreoffice.org/71599 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
- 30 Nis, 2019 8 kayıt (commit)
-
-
andreas kainz yazdı
Change-Id: I595c8494bef7c9dae16ae17bd963c79097f4a4c6 Reviewed-on: https://gerrit.libreoffice.org/71607Reviewed-by: andreas_kainz <kainz.a@gmail.com> Tested-by: andreas_kainz <kainz.a@gmail.com>
-
andreas kainz yazdı
Change-Id: I12c8f7d73f9047e570fa094da82429fa3f523841 Reviewed-on: https://gerrit.libreoffice.org/71605Reviewed-by: andreas_kainz <kainz.a@gmail.com> Tested-by: andreas_kainz <kainz.a@gmail.com>
-
andreas kainz yazdı
Change-Id: I7614637d8b793d7e5329e110448dbdb04ada273d Reviewed-on: https://gerrit.libreoffice.org/71606Reviewed-by: andreas_kainz <kainz.a@gmail.com> Tested-by: andreas_kainz <kainz.a@gmail.com>
-
andreas kainz yazdı
Change-Id: Iaa20611ccde1d53cd85db63cbdab450c1622a303 Reviewed-on: https://gerrit.libreoffice.org/71601Reviewed-by: andreas_kainz <kainz.a@gmail.com> Tested-by: andreas_kainz <kainz.a@gmail.com> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
andreas kainz yazdı
Change-Id: Id0b9a5816ee459837ca8fe2b4dd7a0233a517c0d Reviewed-on: https://gerrit.libreoffice.org/71604Reviewed-by: andreas_kainz <kainz.a@gmail.com> Tested-by: andreas_kainz <kainz.a@gmail.com>
-
Matthias Freund yazdı
Reduced svg size Change-Id: Iccfe353d33f7c78600a1cdf24fd67038831fc692 Reviewed-on: https://gerrit.libreoffice.org/71562 Tested-by: Jenkins Reviewed-by: Matthias Freund <matti_lx@secure.mailbox.org>
-
Miklos Vajna yazdı
Commit a51b7a1c (tdf#103831, tdf#100986: Force using GDI when needed, 2017-03-03) noted that the DirectWrite text renderer doesn't support vertical text, add initial support for this now by extending the DirectWrite transform matrix to do rotation as well. This is initial support, as it can be improved in two ways: - vertical text is not cached - only vertical Latin text is handled, which wants rotated glyphs (vs e.g. Japanese text that would not rotate the glyphs) With this, the "unreadable" text in the bugdoc's chart is on par with the the GDI rendering. Change-Id: I07af4de6cb437f83cc40546396ec8c8aac456bb3 Reviewed-on: https://gerrit.libreoffice.org/71592Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
-
Michael Stahl yazdı
Was recently added in 453e6fb7 Here this goes into an infinite loop, at least it doesn't finish in an hour; Miklos claims it's due to missing fonts, let's just remove the test for now, the file will still be tested by crashtesting. Change-Id: I8acd05e9428ca25d1255b9f14ca56c7a9f5d4f00
-