- 14 Nis, 2019 5 kayıt (commit)
-
-
Mike Kaganski yazdı
V522 There might be dereferencing of a potential null pointer. Change-Id: Ie4bc74a734a6d5a73838a27e0d80cc8e51595839 Reviewed-on: https://gerrit.libreoffice.org/70730 Tested-by: Jenkins Reviewed-by:
Mike Kaganski <mike.kaganski@collabora.com>
-
Mike Kaganski yazdı
Treat xml:space specially in OOXMLFastContextHandler::startFastElement, to allow this attribute to be handled for any element. Change-Id: I81bd1e0642940ffdfc03d6c65d0ce9f421206c5e Reviewed-on: https://gerrit.libreoffice.org/70723Reviewed-by:
-
Noel Grandin yazdı
Change-Id: Iec56b41dba502e438dfdc7a99385545b3efdf8c7 Reviewed-on: https://gerrit.libreoffice.org/70720 Tested-by: Jenkins Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
Noel Grandin yazdı
Change-Id: I465a2479f347303e6d4faa39cb0a0f05aec3bf07 Reviewed-on: https://gerrit.libreoffice.org/70719 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I95d7b67cd8b6b68c087ff96fdb6bb283ab8b49ec Reviewed-on: https://gerrit.libreoffice.org/70718 Tested-by: Jenkins Reviewed-by:
-
- 13 Nis, 2019 28 kayıt (commit)
-
-
Jim Raykowski yazdı
In ToolboxButtonColorUpdater::Update(const NamedColor &rNamedColor) if the color name is empty the check for color name emptiness causes the tool tip to remain unchanged. This produces an incorrect tool tip. Better to show either the hex representation of the color or simply empty. This patch shows the color name as empty. Currently there are not any colors that I know of that have empty color names but with this patch we are ready for them :-) Change-Id: Ia96789b668cb358d7b03904a75e327303411e56d Reviewed-on: https://gerrit.libreoffice.org/70448 Tested-by: Jenkins Reviewed-by:
Jim Raykowski <raykowj@gmail.com>
-
andreas kainz yazdı
Change-Id: I06249915f44800cba6bca9af0a85528328297970 Reviewed-on: https://gerrit.libreoffice.org/70515 Tested-by: Jenkins Reviewed-by:
andreas_kainz <kainz.a@gmail.com>
-
Jens Carl yazdı
Add single quotes around the namespace::class construct, when calling gdb.parse_and_eval(), otherwise this exception is thrown: "Python Exception <class 'gdb.error'> A syntax error in expression, near `)xxx)->count($'.:" The reason is a possible conflict with '::' referring a static variable (https://sourceware.org/gdb/onlinedocs/gdb/Variables.html). Also improved the B2DPolyPolygonPrinter::children method to avoid a segmentation fault, when accessing member m_value. Change-Id: I1c15a4b786e1e374c67ace445d28c1ce210a4c04 Reviewed-on: https://gerrit.libreoffice.org/70537 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I7bd1511a6acc105ab5b42c698c7578cfb9ce06b4 Reviewed-on: https://gerrit.libreoffice.org/70708 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I59ef0a6da411b8af8bdf8d8efb1d733db7475d9c Reviewed-on: https://gerrit.libreoffice.org/70707 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: Ic561f56e1cfe06de219bd7a257186107b5c152fb Reviewed-on: https://gerrit.libreoffice.org/70706 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I69377e2f96a376a7a5ccaec268c4f92c00a250f7 Reviewed-on: https://gerrit.libreoffice.org/70705 Tested-by: Jenkins Reviewed-by:
-
Mike Kaganski yazdı
... follow-up to commits 65f27f55 and eeeec33a Otherwise, e.g. on Windows, linker complains about unknown options /FS and /Zi, and doesn't link debug info, making debug build useless. Change-Id: I256a463b4b4e4bb339c94a393c9b1d17e85b7a3f Reviewed-on: https://gerrit.libreoffice.org/70713Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I95c621615c197687552147b8328c769fdd47befa Reviewed-on: https://gerrit.libreoffice.org/70711 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Justin Luth yazdı
...from LO6.3 commit 8d4a7b17 Footnotes and Endnotes are also considered sections, and those sections are messing up tracking which page style is in effect. Simply reverting since any fix will still be based on page style assumptions and require losts of testing. The original commit didn't fix any reported bug anyway. Change-Id: I3597d511d9755f48e7ac2ae9cfb2f8ff63c74d17 Reviewed-on: https://gerrit.libreoffice.org/70702 Tested-by: Jenkins Reviewed-by:
Justin Luth <justin_luth@sil.org>
-
Caolán McNamara yazdı
Change-Id: I515c756451539527faff59b67e0a8d1ee64c1347 Reviewed-on: https://gerrit.libreoffice.org/70686 Tested-by: Jenkins Reviewed-by:
-
Takeshi Abe yazdı
... of user templates This is kludgy yet better than making innocent users waiting for the template dialog ~forever as pointed out in the comments in <https://gerrit.libreoffice.org/#/c/67741/>. Change-Id: I6dfdc0408effb06cc9175cd976ea6687e52a7136 Reviewed-on: https://gerrit.libreoffice.org/69883 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I98da731a0f6b72ea0cb890dae2f25992c75a0984 Reviewed-on: https://gerrit.libreoffice.org/70701 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I4ba0e1e982897bd570612f6cda8ba1e6a9fa5dbd Reviewed-on: https://gerrit.libreoffice.org/70700 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I95c6fb5e2ddc1c2d8a2fb1d5ff30b18ddad48b3a Reviewed-on: https://gerrit.libreoffice.org/70699 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I3f3108daf208fa8c6be90b28da5503846c27732e Reviewed-on: https://gerrit.libreoffice.org/70698 Tested-by: Jenkins Reviewed-by:
-
Tomaž Vajngerl yazdı
Functions that scaled down had "2" at the end of the name so we could distinguish them from the scale up functions. This was hard to tell them apart, so rename the functions to reflect what they do. Change-Id: I9d88b86312e80b111439f1022212de07e53485d5 Reviewed-on: https://gerrit.libreoffice.org/70696Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com> Tested-by:
-
Tomaž Vajngerl yazdı
Until now we had RGB and BGR version. Because we never change the byte order when scaling and the scanline type, we can generalize the two funcions into one, where we only need to be careful that we don't change the order of color components. The same is done already for 4 variants of 32-bit bitmap, where we really only need 1 function for all 4 variants, using the same principle. Change-Id: I0f6d6b0c06a45e53bcd048e2ae009a471bf90a06 Reviewed-on: https://gerrit.libreoffice.org/70695 Tested-by: Jenkins Reviewed-by:
-
Tomaž Vajngerl yazdı
Most calculations work with integers for speed, which sacrifices some bits of an integer type for decimal values (fixed-point precision). In this case we used 7 bits for decimal values. This change makes the precision easily adjustable. In addition the actual type of bilinar weights, which was until now the type long (that hasn't a standardized bit length), but is now changed to sal_Int32 (so we know exactly how much bits we can use) and can be changed to sal_Int64 in the future if necessary by just adjusting the typedef. Change-Id: I8d41751c20e14cd1b9b64b055ff66bd1ca7c9f1d Reviewed-on: https://gerrit.libreoffice.org/70694 Tested-by: Jenkins Reviewed-by:
-
Jean-Pierre Ledure yazdı
Labels were present for each language in L10N module but applied nowhere.
-
Miklos Vajna yazdı
OpenGL just sets GtkSalGraphics::bNeedPixmapPaint to true, and the problem is specific to that flag (can be also enabled via SAL_GTK_USE_PIXMAPPAINT=1). Most other widgets are painted correctly in the GL case as they pass around a drawable explicitly; do the same for ControlType::ListNode as well in the GL case. The non-GL case still needs to go via the pixmap render macros to have correct position, leave that unchanged. Change-Id: Ia82a6772e357b434d706e58664be3a8427e91669 Reviewed-on: https://gerrit.libreoffice.org/70669 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com>
-
Noel Grandin yazdı
Change-Id: I7d85cbc9105c5e0c4a8d9a69c4ac9d6dfc07eabd Reviewed-on: https://gerrit.libreoffice.org/70663 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: Iaa14545a19956b675ba8bbe0baf5d4ca8d86f518 Reviewed-on: https://gerrit.libreoffice.org/70692Reviewed-by:
Julien Nabet <serval2412@yahoo.fr> Tested-by:
-
Jan Holesovsky yazdı
Not to break the 'old' Android app, introduce a bool that can indicate if we are using the LOK from the 'old' (LOK-via-JNI-based) or from the 'new' (loolwsd-based) app. Change-Id: I38bd665cc1d5bc88018574171443ecabc46763df Reviewed-on: https://gerrit.libreoffice.org/70678Reviewed-by:
Jan Holesovsky <kendy@collabora.com> Tested-by:
-
Noel Grandin yazdı
Change-Id: I9776431ebce95a88ae42715aaba2ddc28fb52471 Reviewed-on: https://gerrit.libreoffice.org/70642Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I2a73e84c9292dabeb5129b4261bb08c959b6b3e4 Reviewed-on: https://gerrit.libreoffice.org/70691 Tested-by: Jenkins Reviewed-by:
Jens Carl <j.carl43@gmx.de>
-
Tomaž Vajngerl yazdı
We still miss the support in other function however. Change-Id: Ie87b588a9f8826242f4cff9d6671c98f3407f0e3 Reviewed-on: https://gerrit.libreoffice.org/70679 Tested-by: Jenkins Reviewed-by:
-
Tomaž Vajngerl yazdı
The old approach was to calculate the number of stripes of the bitmap per thread and later create the exact number tasks (ScaleTask) as there are threads, where each task would process stripes it had been given. This is needlesly complicated as the job of a thread pool is to properly delegate the tasks between threads. This was now changed so that we create one stripe per ScaleTask and let the threadpool delegate the tasks to its threads (that are available). It also wanted to be clever and use the main thread to do the work also, but it had a major flaw. The threadpool started to process the tasks only when "waitUntilDone" method was called, but the code first processed its slices and then called the threadpool method to start processing. Because of this the performance of scaling wasn't as good as it could be. This behaviour was now changed so that the main thread isn't involved in processing. It just creates the task, runs the threadpool and waits until the tasks are finished. Change-Id: I1e8c733bdbced8867d0a7f1190f0421a0cc3e067 Reviewed-on: https://gerrit.libreoffice.org/70668Reviewed-by:
-
- 12 Nis, 2019 7 kayıt (commit)
-
-
Caolán McNamara yazdı
Change-Id: If03c6ff8043bb39f2efdf4cde19d8277886bf36f Reviewed-on: https://gerrit.libreoffice.org/70658 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
probably missed loads more Change-Id: I53c9fe188055ef925fed54500e64b837cd56a1e7 Reviewed-on: https://gerrit.libreoffice.org/70676 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I211114140afc3f5b32b8b034e63e8d52f78be36a Reviewed-on: https://gerrit.libreoffice.org/70659 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I321c8eefdc43979ef5fd3774c7094ac0dbcac417 Reviewed-on: https://gerrit.libreoffice.org/70657 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
and so triggering a crash and exit on trying to get address of 0th element of a 0 len vector Change-Id: I205478b6c2878d3758d91812db46fe8ad58e37df Reviewed-on: https://gerrit.libreoffice.org/70672 Tested-by: Jenkins Reviewed-by:
-
Mike Kaganski yazdı
Two tests in sc/qa/unit/pivottable_filters_test.cxx were extended to also test round-trip of group fields in XLSX. Change-Id: I70b7c15b09040c64fa1da2f88001af7ba16f2c6f Reviewed-on: https://gerrit.libreoffice.org/69653 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I066b74763e45c785a9ebd7094fc33f44b8ddefb6
-
