- 24 Nis, 2019 1 kayıt (commit)
-
-
Tomaž Vajngerl yazdı
This should prevent the crash - at least it did for me AFAICS. Change-Id: I489264d8054e6577b948b0ab307c863d3140788a Reviewed-on: https://gerrit.libreoffice.org/70755 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 9f392d0c) Reviewed-on: https://gerrit.libreoffice.org/70914Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de>
-
- 23 Nis, 2019 7 kayıt (commit)
-
-
Miklos Vajna yazdı
Regression from commit 59339dec (tdf#105150 PPTX import: try harder to handle <p:sp useBgFill="1">, 2017-01-06), the problem was that we gave a white solid fill to a shape which is meant to be transparent. Fix the problem by limiting the scope of the mentioned commit to solid colors only, and also extend to code to look for background fill from the masterpage as well. This allows not hardcoding the white solid fill and leaves the fill style of shapes as transparent where the slide background is a bitmap or other more complex fill type. (cherry picked from commit 943a534a) Change-Id: I0063e88d510250652d2b14856df3bd431681422d Reviewed-on: https://gerrit.libreoffice.org/71115 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Caolán McNamara <caolanm@redhat.com>
-
Caolán McNamara yazdı
because NSS_Init wasn't called first Change-Id: Ib1b4c950dc2773af1fea7b64339b86566ee412e7 Reviewed-on: https://gerrit.libreoffice.org/70949Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> Tested-by: Jenkins
-
Tomaž Vajngerl yazdı
IsPaintTransparent() is preventing to paint the background but not sure why this is needed. removing this condition doesn't seem to have any ill effects. Reviewed-on: https://gerrit.libreoffice.org/70855 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 1e917af2) Change-Id: I5ac54e208e4f1c9941beb4012aa44182d21dbed9 Reviewed-on: https://gerrit.libreoffice.org/70916 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com>
-
Caolán McNamara yazdı
Change-Id: If03c6ff8043bb39f2efdf4cde19d8277886bf36f Reviewed-on: https://gerrit.libreoffice.org/70677 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com>
-
Caolán McNamara yazdı
Change-Id: I831d0dd62d0b28dc19b90b03de3eaa159984347c Reviewed-on: https://gerrit.libreoffice.org/70923 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de>
-
Miklos Vajna yazdı
Commit 3e009203 (tdf#112318 sd opengl: fix lack of initial animation, 2019-04-05) enabled processing of idle events between two updates of the slideshow to help OpenGL, which uncovered a problem with media shapes. On one hand, slideshow::internal::ViewMediaShape::implInitializePlayerWindow() calls EnablePaint(false) on the media window. OTOH, vcl::Window::ImplCallPaint() handles mbPaintDisabled by invalidating the relevant area of the window, which causes a paint<->invalidate loop. Fix the problem by nominally still enabling paints on the media window: nothing will change in practice (since the actual media overlay will be on top of it), but this way the loop goes away. mbPaintDisabled is handled like this since the initial import, the media window flag was added much later, so it makes more sense to adapt the later. (cherry picked from commit d7f4f565) Conflicts: slideshow/source/engine/shapes/viewmediashape.cxx Change-Id: Ib89b68d93aa9d09dbcad33eb6e75a8a25ef1b752 Reviewed-on: https://gerrit.libreoffice.org/70886 Tested-by: Jenkins Reviewed-by:
Luboš Luňák <l.lunak@collabora.com>
-
Julien Nabet yazdı
Change-Id: Ie3e713786b096657571d0abe0806b1d45d2b5341 Reviewed-on: https://gerrit.libreoffice.org/69585 Tested-by: Jenkins Reviewed-by:
Andras Timar <andras.timar@collabora.com> (cherry picked from commit 1971c61a) Reviewed-on: https://gerrit.libreoffice.org/69645Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
- 20 Nis, 2019 2 kayıt (commit)
-
-
Michael Stahl yazdı
Change-Id: I3fe30de8140dce3d81cdfae7d41e0bd465b1d5f4 Reviewed-on: https://gerrit.libreoffice.org/70879 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 2d85b75b) Reviewed-on: https://gerrit.libreoffice.org/70893Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Michael Stahl yazdı
... that happens when you accept a delete redline (or reject an insert redline) with such end pos. The problem is that first a DeleteRange() will move the anchor position onto the table node (because check in SwUndoSaveContent::DelContentIndex() is surprisingly asymmetric and so the fly not deleted by the previous bugfix), then DelFullPara() creates a second SwUndoDelete then deleting the fly crashes because its anchors was moved. The code in lcl_AcceptRedline() / lcl_RejectRedline() doesn't make much sense (but always was like this), if we just call DeleteFullPara() once instead, the problem is avoided, and we don't even have to worry about why DelContentIndex() is so asymmetric (is "selection direction" really a meaningful concept?). Reportedly this started to crash with commit e07feb94, previously it was just wrong. Change-Id: Ib3d4b31e0255a6f4e7b49b40f204dec168ea3006 Reviewed-on: https://gerrit.libreoffice.org/70836 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit f83e22f5) Reviewed-on: https://gerrit.libreoffice.org/70865Tested-by:
Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
- 18 Nis, 2019 5 kayıt (commit)
-
-
Stephan Bergmann yazdı
...merging <https://github.com/flathub/org.libreoffice.LibreOffice/commit/ 2c72c8b2c9beb4995c5a57b4eedf05f6c7ff248d> "Disable OpenCL by default for LO Flatpak": "This fixes <https://github.com/flathub/org.libreoffice.LibreOffice/issues/82> 'LibreOffice cannot be launched with flatpak in normal mode on ASUS E402YA', where LO was found hanging (for as yet unclear exact reasons) on one machine when OpenCL was enabled. There have been other issues with OpenCL like <https://bugzilla.redhat.com/show_bug.cgi?id=1432468> 'LibreOffice crashes on startup' on Fedora, so for a Flatpak build targeting a wide range of distros, the conservative approach is probably to disable OpenCL by default and have users explicitly enable it instead." Change-Id: I887137d1ceb5d97f007f09cba636c59f197f1bff Reviewed-on: https://gerrit.libreoffice.org/70928 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit db698a94) Reviewed-on: https://gerrit.libreoffice.org/70931
-
Katarina Behrens yazdı
Two use-cases here in kde5backend 1) kde or qt vclplug has already started qt event loop => just use this loop to read KDE settings 2) no qt event loop runs (we're most likely in gtk3_kde5 vclplug) => start a new event loop, read the settings and stop it In case 2) letting qt event loop run means subsequently all UI ops need to happen in main thread. This is problematic to enforce in non-qt-based vclplugs In both cases, cache those settings for future use - the assumption is, most of them are static during a session anyway. Change-Id: Ifa203f4cdb9a753db808f945762fb131ee83393c Reviewed-on: https://gerrit.libreoffice.org/70808 Tested-by: Jenkins Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit 5a64bc2b) Reviewed-on: https://gerrit.libreoffice.org/70895Reviewed-by:
Michael Weghorn <m.weghorn@posteo.de>
-
Tamás Zolnai yazdı
Change-Id: I00df0022a20e83d76484d7c6e7b903ecd3c54aa0 Reviewed-on: https://gerrit.libreoffice.org/70347 Tested-by: Jenkins Reviewed-by:
Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit 84d4125b) Reviewed-on: https://gerrit.libreoffice.org/70454Reviewed-by:
Miklos Vajna <vmiklos@collabora.com>
-
Caolán McNamara yazdı
which for the common case avoids the narrowing of hidpi outputdevices through non-hidpi bitmaps Change-Id: Ibdc004a0946e8cb118818e58a01e5791c869353a Reviewed-on: https://gerrit.libreoffice.org/69930 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Caolán McNamara <caolanm@redhat.com> (cherry picked from commit b1f961e3) after... copy between the outputdevices without interim Bitmap Change-Id: I6c0097b1b069cad2771c94210986714d59431e4f Reviewed-on: https://gerrit.libreoffice.org/69929 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 11fe18ea) Reviewed-on: https://gerrit.libreoffice.org/69938Reviewed-by:
Miklos Vajna <vmiklos@collabora.com>
-
David Vogt yazdı
In old versions of LO/AOO, separator style was defaulting to a solid line. When you have an old document that doesn't have the style set explicitly, the line would disappear. Since newer versions explicitly set the style, we should set the default to what it was before. Change-Id: I8dacea75fcf2f95f9bc145442b22ab0d173e7c5a Reviewed-on: https://gerrit.libreoffice.org/69167 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 4aa8a6ab) Reviewed-on: https://gerrit.libreoffice.org/70892Reviewed-by:
Xisco Faulí <xiscofauli@libreoffice.org>
-
- 16 Nis, 2019 6 kayıt (commit)
-
-
Michael Stahl yazdı
nLen may be larger than the master SwTextFrame, but its follow can't have negative offset. (regression from 0acde751) Change-Id: I6177c748480cdf61e8f15a7032ba52d3ae2ea52c Reviewed-on: https://gerrit.libreoffice.org/70816 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 2ea6f385) Reviewed-on: https://gerrit.libreoffice.org/70821Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Michael Stahl yazdı
... due to change of default argument; the XHTML export is calling it from SwXTextPortion::getString(). This is complicated a bit by a bunch of changes to GetExpandText() callers. (regression from bf488abb) Change-Id: I0b1e10e17c8f3824d6fa1f21fc74cc59b310474f Reviewed-on: https://gerrit.libreoffice.org/70791 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit f32ddd38) Reviewed-on: https://gerrit.libreoffice.org/70809Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
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. (cherry picked from commit fb9c7e31) Change-Id: Ia82a6772e357b434d706e58664be3a8427e91669 Reviewed-on: https://gerrit.libreoffice.org/70762 Tested-by: Jenkins Reviewed-by:
Luboš Luňák <l.lunak@collabora.com>
-
Dennis Francis yazdı
ScDPCache field labels, else on export to xlsx, Excel will fail to load the pivot table due to case-insensitive duplicate field labels in the pivotCacheDefinition1.xml. This could be done just for xlsx export filter, but we do normalization in dpcache.cxx anyway and it would not hurt if we do a case-insensitive normalization here. The private member ScDPCache::AddLabel had code duplication and more importantly it is called in loop for every label in the database so results in O(n^2) time complexity where n is the number of labels, so removed it to reuse normalizeLabels() at the only call-site. Also added a unit test that checks case-insensitive normalization. Change-Id: Id563dee232a98a2aea9f4fc29254f6942e1c5ba7 Reviewed-on: https://gerrit.libreoffice.org/70498Reviewed-by:
Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins Reviewed-by:
Dennis Francis <dennis.francis@collabora.com> (cherry picked from commit 238cadd3) Reviewed-on: https://gerrit.libreoffice.org/70703
-
Dennis Francis yazdı
under colFields tag if there is only one data-field. <colFields count=[*]> <field x="-2"/> <--- -2 indicates data field. </colFields> Excel 2013/2016 seems to crash at the presence of '<field x="-2"/>' in colFields when there is only one data-field. Additionally, call GetOutputRangeByType(sheet::DataPilotOutputRangeType::TABLE) on all ScDPObject's in non-const mode, so that the internal pOuput member of ScDPObject is populated. Otherwise the const GetOutputRangeByType(sheet::DataPilotOutputRangeType::TABLE) call always return an invalid range. This also adds 2 unit tests :- 1. To check the presence of <field x="-2"/> in colFields tag if there are more than one data-fields. 2. To ensure the absence of <field x="-2"/> in colFields tag if there is only one data-field. Change-Id: I8f470bd1ab883f73586f04a3fcc30e3fbf948c4a Reviewed-on: https://gerrit.libreoffice.org/70316 Tested-by: Jenkins Reviewed-by:
Andras Timar <andras.timar@collabora.com> (cherry picked from commit 97af5809) Reviewed-on: https://gerrit.libreoffice.org/70704Reviewed-by:
Dennis Francis <dennis.francis@collabora.com>
-
Michael Weghorn yazdı
Store the file extension associated with the named filters in a map, and use that information to set the default file extension in QFileDialog accordingly if the corresponding checkbox in the dialog is enabled. Change-Id: I66f4f35da5d4378ac6337429e39260a4ed710a24 Reviewed-on: https://gerrit.libreoffice.org/67392 Tested-by: Jenkins Reviewed-by:
Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 9a6818bd) Reviewed-on: https://gerrit.libreoffice.org/70763Reviewed-by:
Katarina Behrens <Katarina.Behrens@cib.de>
-
- 15 Nis, 2019 4 kayıt (commit)
-
-
Michael Stahl yazdı
Commit 6ff263b8 added a check in SwUndoSaveContent::DelContentIndex() to avoid moving the anchor of a FLY_AT_PARA if its new position would be a table node, because SwFlyAtContentFrame::Modify() requires a SwTextNode to be the anchor. However, that doesn't actually avoid moving the anchor - later, SwNodes::RemoveNode() relocates the anchor to the next node regardless of type! It's probably better to just delete the fly in the situation when the end position is a SwTableNode, which fixes the reported crash. Unfortunately on Redo, the SwUndoDelete::UndoImpl() does not recreate the nodes correctly, hence the fly then is inserted on the wrong node, which later crashes again. The problem is that due to the table node, a dummy SwTextNode is inserted, which should be at the end of the range, but ends up at the start due to an erroneous ++aPos.nNode; - the result is that the fly is inserted on the dummy node and is immediately deleted again, triggering another assert. If there is a dummy node, it also doesn't make sense to call SplitNode(). Yet another problem is that in SwUndoDelete::UndoImpl(), the frames for the moved text nodes are not created, because the first node is skipped with the wrong assumption that it already has frames. Reportedly this started to crash with commit e07feb94, previously it was just wrong. Reviewed-on: https://gerrit.libreoffice.org/70683 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 80b73dcc) Change-Id: I5094638e34c6ed52c836e57691d377b8cd1608f9 Reviewed-on: https://gerrit.libreoffice.org/70764 Tested-by: Jenkins Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Caolán McNamara yazdı
Change-Id: If382f0419c8ea0a3b99c85942c05ee1e5a627e76 Reviewed-on: https://gerrit.libreoffice.org/70796 Tested-by: Jenkins Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
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/70673Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> Tested-by:
Michael Stahl <Michael.Stahl@cib.de>
-
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:
Mike Kaganski <mike.kaganski@collabora.com> Tested-by:
Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/70725 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de>
-
- 13 Nis, 2019 2 kayıt (commit)
-
-
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/70709 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Caolán McNamara <caolanm@redhat.com>
-
Michael Stahl yazdı
It turns out that the situation fixed in commit 1be0a3fa also applies to the definition of the styles themselves. To implement the same style import as Word, the style definitions need to be stored twice: once as read from the file, and another time with attributes defaulted and deduplicated vs. the parent style; the second representation is then sent to the domain mapper. To make this easier, add a bool parameter to cloneAndDeduplicate() to disable the implicit pPr dereferencing that happens when creating the hard formatted paragraph properties (this could potentially be cleaned up further if those paragraph properties would use pPr wrapper themselves). Also implement defaulting of line spacing in getDefaultSPRM(). Reviewed-on: https://gerrit.libreoffice.org/70320 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 3d74ddd1) Change-Id: I4810e917697b3af244e5dbdd7f5a45b4767c93fc Reviewed-on: https://gerrit.libreoffice.org/70508 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Caolán McNamara <caolanm@redhat.com>
-
- 12 Nis, 2019 4 kayıt (commit)
-
-
Stephan Bergmann yazdı
Reviewed-on: https://gerrit.libreoffice.org/70638 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit bc8b40ec) Conflicts: solenv/flatpak-manifest.in Change-Id: I9b8bb016721f35032fe214f977f9463c241084ea Reviewed-on: https://gerrit.libreoffice.org/70649 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: If42b676c3321d73455771b6ea62aefb806caccd2 Reviewed-on: https://gerrit.libreoffice.org/70674Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
Caolán McNamara yazdı
refactor and reuse existing dialog to add potential domain entry Change-Id: Ib884931f8ccc62aad9b3e92ecf93d1da7ffe607b Reviewed-on: https://gerrit.libreoffice.org/69765 Tested-by: Jenkins Reviewed-by:
Xisco Faulí <xiscofauli@libreoffice.org>
-
Patrick Jaap yazdı
In a previous commit only x/y coordinate were considered. For better overview make use of the OOXML converter for orients and relations. Change-Id: I9792ccfbc2ebb58fd768c14278cdfd9b54efe62f Reviewed-on: https://gerrit.libreoffice.org/69523 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/70589
-
- 11 Nis, 2019 5 kayıt (commit)
-
-
Stephan Bergmann yazdı
After recent additions of 61c4f96d "Support AdoptOpenJDK" and 41507db5 "Support Amazon Corretto" to our hard-coded list, there is now reports that at least Debian and Ubuntu tried to distribute versions of OpenJDK with the java.vendor propety set to string like "Debian" or "Ubuntu". Instead of trying to catch up with an ever-growing hard-coded list, it is probably better to stop relying exclusively on such a hard-coded list, and for unknown vendor values, try out whether the SunInfo backend (which supports the "generic" OpenJDK) would be able to handle the given JRE. (For simplicity, assume that any versions of such JREs are supported. Our baseline is Java 6, and there are unlikely any older versions of JREs from unknown vendors out there. If this turns out to be problematic, we could include information about problematic vendors after all, or add a general check that JREs from unknown vendors are at least Java 6.) Many functions in jvmfwk/inc/vendorplugin.hxx that used to take a set of sVendor/sMinVersion/sMaxVerison/arExcludeList paramters had to be revised to take a vendorSettings parameter instead, and VendorSettings::getVersionInformation has been changed to return a boost::optional, so that unknown vendors can be handled gracefully. Change-Id: Ibf915f2ddd59e09b77e2c03be688cac0547b9ac9 Reviewed-on: https://gerrit.libreoffice.org/70460 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 3d27b2fa) Reviewed-on: https://gerrit.libreoffice.org/70586Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Caolán McNamara <caolanm@redhat.com>
-
Miklos Vajna yazdı
Actually this is not specific to opengl, affects e.g. the Linux gen backend as well, it just doesn't happen with the Windows gdi backend. The rendering of the caption itself was OK. Focusing on the arrow polygon at the end of the comment's "tail" (connector polyline): - What gets painted is determined by SdrCaptionObj -> ViewContactOfSdrCaptionObj::createViewIndependentPrimitive2DSequence(), which produces a PolyPolygonColorPrimitive2D, which is then processed by VclPixelProcessor2D::tryDrawPolyPolygonColorPrimitive2DDirect(). - The polygon passed to VCL there is within the bounds of the invalidation rectangle set in ScNoteMarker::TimeHdl(). So it seems the only reason sometimes these 1px rendering artifacts are left around is anti-aliasing. Fix those by simply extending the invalidation rectangle in each direction. (cherry picked from commit 37aa4f0d) Change-Id: I37b8e666999d3ff5ee1328fca7ac017ee8c7e9e0 Reviewed-on: https://gerrit.libreoffice.org/70585 Tested-by: Jenkins Reviewed-by:
Luboš Luňák <l.lunak@collabora.com>
-
Tomaž Vajngerl yazdı
When we drag a entry in TreeListBox, we execute a PaintDDCursor which paints a "cursor" of a possible drag target (for example to show where the entry will be moved to if we want to change the order). The problem with this fuction is that it paints a line directlly at that location, and that it uses invert raster operation to draw a line. So to hide the line it just needs to draw again. On MacOS this invertion causes a problem and draws the whole area black, which is the cause of this bug. So instead of inverting the drawing of the drag target cursor has now been moved into the main Paint method, where it redraws the whole entry, and if present, also the drag target cursor. This means that all we need to do is Invalidate the entry, which then just gets redrawn in a normal Paint pass. One exception is still MacOS, which doesn't invalidate the entry, but redraws the entry directly. DnD is MacOS is a bit different as it is not async (if I understand correctly) so the invalidate has no effect. Change-Id: I8542f47940a3b90114ea4bbbac57fd303ca3434b Reviewed-on: https://gerrit.libreoffice.org/70521 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 14abbc6e) Reviewed-on: https://gerrit.libreoffice.org/70526Reviewed-by:
Andras Timar <andras.timar@collabora.com>
-
Patrick Jaap yazdı
Change-Id: I47093292aeed5c0579dd4b365561ee86935632e4 Reviewed-on: https://gerrit.libreoffice.org/70197 Tested-by: Jenkins Reviewed-by:
Julien Nabet <serval2412@yahoo.fr> (cherry picked from commit 2111f607) Reviewed-on: https://gerrit.libreoffice.org/70513Reviewed-by:
Miklos Vajna <vmiklos@collabora.com>
-
Michael Weghorn yazdı
S.a. commit 8dbe0af7 which already did the same for Gtk3KDE5FilePicker. Change-Id: I35f837b7b8fdaebc5625ff8ea5e20b3f48a3b4ec Reviewed-on: https://gerrit.libreoffice.org/70519 Tested-by: Jenkins Reviewed-by:
Michael Weghorn <m.weghorn@posteo.de> (cherry picked from commit 728ee383) Reviewed-on: https://gerrit.libreoffice.org/70529Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de>
-
- 10 Nis, 2019 3 kayıt (commit)
-
-
Michael Stahl yazdı
Missed one call where the return value must be forwarded. (regression from 7d481f7a and 943d9be7) Change-Id: Ic405b29a1dce982bfdd81eeb5d678ceb79690bfc Reviewed-on: https://gerrit.libreoffice.org/70469 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 0017c9b5) Reviewed-on: https://gerrit.libreoffice.org/70501Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Michael Stahl yazdı
(regression from c180c944) Change-Id: Ie3c935ee5dd42187ca8ad2b28406b80e63c0d1e3 Reviewed-on: https://gerrit.libreoffice.org/70467Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> Tested-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 7587e390) Reviewed-on: https://gerrit.libreoffice.org/70500 Tested-by: Jenkins Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Patrick Jaap yazdı
Until now we exported the original x/y position values of the table from the grabbag. Ignoring users actions like moving the table around. Now, we compute the position from the parent frame and write the actual position in the docx file. Change-Id: I25a09f9c7c8fbe49acbd19e2b1440c7fa90b8aff Reviewed-on: https://gerrit.libreoffice.org/67969 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 4f30b2ab) Reviewed-on: https://gerrit.libreoffice.org/70306
-
- 09 Nis, 2019 1 kayıt (commit)
-
-
Christian Lohmaier yazdı
* Update translations from branch 'libreoffice-6-2' - update translations for 6.2.3 rc2 and force-fix errors using pocheck Change-Id: I17d9e99f7d51c2995ce361a893fdd7ca7078ab74
-