- 03 Haz, 2019 8 kayıt (commit)
-
-
Katarina Behrens yazdı
Fix of tdf#41996 is a workaround of kde4-specific condition and has been since disabled on OS X (as tdf#51023). kde5 comes with a new implementation of DnD and slide sorter in Impress now exhibits exactly the same symptoms as on OS X in tdf#51023 Assuming that in 6.2 kde5 doesn't need this workaround anymore and remaining platforms -- gtk[23] and Win -- never had issues with DnD in slide sorter, keep it active only for kde4 vclplug. We can't kill it with fire in its entirety, because kde4 has been obsoleted only post-6.2 Change-Id: I1fd8bb9e5142effffbd43f3a8bead417832c808c Reviewed-on: https://gerrit.libreoffice.org/73403 Tested-by: Jenkins Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Caolán McNamara yazdı
Change-Id: I499e32ce86fabd18c52ac2f99713af0933572f7c (cherry picked from commit abd6f2a3) Reviewed-on: https://gerrit.libreoffice.org/73395 Tested-by: Jenkins Reviewed-by:
Katarina Behrens <Katarina.Behrens@cib.de>
-
Michael Weghorn yazdı
Handle special values for offset in 'Qt5AccessibleWidget::attributes' the same way that the base class's 'QAccessibleTextWidget::attributes' does, s. [1]. In particular, an offset matching the text length can be passed e.g. by "accerciser" or screen readers, which previously resulted in an 'IndexOutOfBoundsException' being thrown when the index was later checked in the call to 'VCLXAccessibleStatusBarItem::getCharacterAttributes'. See also 'IAccessibleText::attributes' documentation at [2] and the page on special offset values referenced there [3]. [1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/accessible/qaccessiblewidgets.cpp?h=5.12.4#n791 [2] https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_text.html#a29e5c8f69ec13c683ed6bca53333e6a5 [3] https://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_general_info.html#_specialOffsets Change-Id: I623995aeb689b31c5b49fb3ace8e4dd4c18927d2 Reviewed-on: https://gerrit.libreoffice.org/73225 Tested-by: Jenkins Reviewed-by:
-
Grzegorz Araminowicz yazdı
* both width and height of children and space is taken from constraints * better handling of space between children (not lost in some cases) * children centered in the other axis Change-Id: I25b8360790de0292b2b5c313dfa55e58dc042193 Reviewed-on: https://gerrit.libreoffice.org/73201 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/73259
-
Grzegorz Araminowicz yazdı
currently for every node we were additionaly loading constraints from parent node, merging them and then deleting it makes more sense just to keep already loaded constraints from parent node Change-Id: I3fcd669547f24eeeac0b77876950ff7436bd5cb3 Reviewed-on: https://gerrit.libreoffice.org/73116 Tested-by: Jenkins Reviewed-by:
-
Grzegorz Araminowicz yazdı
so that they are laid out in correct order Change-Id: I82baa61311197880654d09f356decc666e6fa4c7 Reviewed-on: https://gerrit.libreoffice.org/73094 Tested-by: Jenkins Reviewed-by:
-
Grzegorz Araminowicz yazdı
up to maximal size of primFontSz constraint. Do not override text size changed by user. Change-Id: If7ea6bbb96cb839831d877edc274a1b0eefdaf21 Reviewed-on: https://gerrit.libreoffice.org/73050 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I570af8f19468730aad714425492f69d05c0a0cf3 Reviewed-on: https://gerrit.libreoffice.org/72853 Tested-by: Jenkins Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
- 01 Haz, 2019 4 kayıt (commit)
-
-
Katarina Behrens yazdı
such as PI() or TRUE() Change-Id: I1243e6d6da7ac884d93d5d46058d94eb35f848ab Reviewed-on: https://gerrit.libreoffice.org/73242 Tested-by: Jenkins Reviewed-by:
Eike Rathke <erack@redhat.com> (cherry picked from commit ad2acdfa) Reviewed-on: https://gerrit.libreoffice.org/73295
-
Takeshi Abe yazdı
... installed on Windows. Change-Id: I2a4d846265b69f0e46e4c711430689ce39d60fcd Reviewed-on: https://gerrit.libreoffice.org/73211Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> Tested-by:
Xisco Faulí <xiscofauli@libreoffice.org>
-
Christian Lohmaier yazdı
Sandboxing prevents access to files in user profile as well as to contents of the LibreOffice.app unless it is manually triggered by the user. Even a clicking a link pointing to the files on an automatically opened file is not enough, the user would have to copy'n'paste the target. As a workaround force online help when default browser is Safari and running on 10.14 or later. (other browsers don't seem to enforce sandboxing yet and continue to work) also fix error in the meta tag for the intermediate page (delay and URL are both part of the content attribute and not separate) Change-Id: I6cc50ec1b1928c2416fdfef4cf50e2196a8594ae Reviewed-on: https://gerrit.libreoffice.org/73163Tested-by:
Olivier Hallot <olivier.hallot@libreoffice.org> Reviewed-by:
Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 44893662) Reviewed-on: https://gerrit.libreoffice.org/73245Reviewed-by:
-
Eike Rathke yazdı
... while temporarily interpreting from within the Function Wizard. Change-Id: I88e7e062989ed395accd50ed9bfe1b76b3b297ea Reviewed-on: https://gerrit.libreoffice.org/73290Reviewed-by:
-
- 31 May, 2019 8 kayıt (commit)
-
-
Katarina Behrens yazdı
Change-Id: I55b4ab8ec5059110525c5194e1133c65bbd07fec Reviewed-on: https://gerrit.libreoffice.org/73183 Tested-by: Jenkins Reviewed-by:
-
Katarina Behrens yazdı
This just stops the bleeding (crash) in a special case when screen number argument of SalFrame::ShowFullScreen is -1 (meaning 'fullscreen spanning all available displays') It doesn't yet extend the fullscreen window over all screens, this will be done in a follow-up fix Change-Id: I2cf48096a1fe1ec33c943f10acb41c59585b325f Reviewed-on: https://gerrit.libreoffice.org/71965 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
Followup to 58f121ef; OConnection must not be held by rtl::Reference as that creates a cycle. (regression from 497e40ad) Change-Id: Ibd56d335e3e2631c5a57ea435f1035e89868a5a6 Reviewed-on: https://gerrit.libreoffice.org/73155 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
Followup to 96ae2a33; more overridden acquire() creating cycles in dbaccess. (regression from 2660d24a) Reviewed-on: https://gerrit.libreoffice.org/73158Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
Grzegorz Araminowicz yazdı
Solved by adding additional shape filling whole diagram. MS PowerPoint does the same when converting SmartArt to shapes. Background shape is also copied when loading from drawingML fallback, appearently there is no background information. Corrected SmartArt import tests, so that they are aware of extra shape. Change-Id: I6154f8e1b34e5867ab582d6fc54459c7c93edbac Reviewed-on: https://gerrit.libreoffice.org/72012 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
kde5 plugin on Wayland still shows too many issues, like e.g. tdf#123654 and was barely tested, so don't use it by default in libreoffice-6-2 branch, but prefer gtk3. This does not affect the X11 case. This reverts commit 3e447810. Change-Id: I7f74a6b5f377f65b81cf5ae189e8672bdce82c95 Reviewed-on: https://gerrit.libreoffice.org/73193 Tested-by: Jenkins Reviewed-by:
Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by:
Michael Weghorn <m.weghorn@posteo.de>
-
Tamás Zolnai yazdı
Revert of: 2903c5f5 Reverting this commit does not lead to the original bug to come back, so we can revert it without a problem. Change-Id: I244a6b9451c47e1094db8a77c71b6696e0c464cc Reviewed-on: https://gerrit.libreoffice.org/73139Reviewed-by:
Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by:
Andras Timar <andras.timar@collabora.com>
-
Tamás Zolnai yazdı
Revert the commit caused this regression: 0fc41c53 The original issue does not come back with reverting this commit. Reviewed-on: https://gerrit.libreoffice.org/72679 Tested-by: Jenkins Reviewed-by:
-
- 30 May, 2019 3 kayıt (commit)
-
-
Mark Hung yazdı
Have video fit to the media object size on the slide, allow more complicated interactions. --- This also backports the relevant part from commit bbe1ede0 ("tdf#124027: use ID of the embedded window and fix position of overlay") namely to make translation gtk3-specific, to fix a regression, as mentioned in its commmit message: > 2) the position of the embedded window for video overlay has already > been translated relative to the top-left corner of the slide (see > bugfix of tdf#42873 how) in gen, gtk and kde5 vclplugs. So let's limit > translating it 2nd time only to gtk3 vclplug which for some reason > behaves differently > (regression from 18138417) Reviewed-on: https://gerrit.libreoffice.org/67978 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Mark Hung <marklh9@gmail.com>
-
Julien Nabet yazdı
See https://bugs.documentfoundation.org/show_bug.cgi?id=56738#c3 Change-Id: I8dbab3fe76b2c2d83cbb07509fabe9f784664c03 Reviewed-on: https://gerrit.libreoffice.org/73088 (cherry picked from commit fd01ddd3) Reviewed-on: https://gerrit.libreoffice.org/73157 Tested-by: Jenkins Reviewed-by:
-
Jan-Marek Glogowski yazdı
You can't tab into the menu bar, but if you add a corner widget, it will be enlisted in the parent's focus chain! Interestingly the menu bar even is considered to have the focus, if the widget is focused, and will handle key events, but this can probably be considered consistent. So this just denies the button any focus, as this is a mouse-only widget, and clicking it will close the document window. Change-Id: I3c48d85ca56b6a54daf01f444dddc736e7ebb8e7 Reviewed-on: https://gerrit.libreoffice.org/73186 Tested-by: Jenkins Reviewed-by:
-
- 29 May, 2019 4 kayıt (commit)
-
-
Xisco Fauli yazdı
Same problem as in 96ae2a33 Regression from 497e40ad Change-Id: I00e7bf3559e688e7fbc5429ace2b5c18221c9890 Reviewed-on: https://gerrit.libreoffice.org/73146Reviewed-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. (cherry picked from commit c04169c5) Change-Id: Ib24f4999ad3e8cbbecc058368e9d112e106e9178 Reviewed-on: https://gerrit.libreoffice.org/72726 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com>
-
Miklos Vajna yazdı
Windows (by default) and gtk3 paints its own background, but e.g. the Linux gen backend does not; so make sure that we not only copy from the buffer, but also initialize it. This restores the gradient background of the main menu with the Linux gen backend. (cherry picked from commit a2da909a) Change-Id: I5ce8cc734f64bc1d57d343caf22071e6aa63a69f Reviewed-on: https://gerrit.libreoffice.org/72685Tested-by:
-
Miklos Vajna yazdı
Regression from commit 458a827e (further refactor Menu to use RenderContext, 2015-05-15), if we do full paint instead of incremental paint, then need to ensure that an intermediate state is not painted. Paint happens at idle time by default on Windows (OpenGL) and also on Linux (gtk3), but some other backends like Windows GDI had flicker, this fixes the problem. (cherry picked from commit e8d5b8be) Change-Id: I530166cea93513aec4648dd0a385359f4b998b6f Reviewed-on: https://gerrit.libreoffice.org/72673 Tested-by: Jenkins Reviewed-by:
-
- 28 May, 2019 1 kayıt (commit)
-
-
Caolán McNamara yazdı
and if there is no videosink then give up Change-Id: I6b60e7be1e77dbf5c4c277ccf47a4d121f3cd6a5 Reviewed-on: https://gerrit.libreoffice.org/72871Reviewed-by:
-
- 27 May, 2019 2 kayıt (commit)
-
-
Cor Nouws yazdı
This reverts commit 2b0cb3cf. As per tdf#125371 there are changes in existing documents in cells that are re-calculated on file-open. IMO this needs to be fixed before this patch can be re-applied. As such there is no question on the changed settings in the Options. Change-Id: Ib748cc520d4d475097cd5fd7e5500456b34f0789 Reviewed-on: https://gerrit.libreoffice.org/72860 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
like SfxHintId::ScAccCursorChanged does Change-Id: I75ab2da866a345d817e39536ac966d3edf24b90a Reviewed-on: https://gerrit.libreoffice.org/72980 Tested-by: Jenkins Reviewed-by:
-
- 24 May, 2019 6 kayıt (commit)
-
-
Jan-Marek Glogowski yazdı
The parameter value for '--accept' is no UNO-Url, but uses a similar syntax. This was wrongly changed in commit d78f29ab ("tdf#100836 "Starting the LibreOffice Software With Parameters" help update"). So this changes the parameter value back to {accept-string}, documents its syntax and adds some common examples. Includes commit a82eed1e ("Fix typo in help: 'urb' => 'urp") (cherry picked from commit a82eed1e) Reviewed-on: https://gerrit.libreoffice.org/72859Reviewed-by:
Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins (cherry picked from commit a4066c77) Change-Id: If8159b1d982c54e3dca6d27a1c400d2450ff2d1e Reviewed-on: https://gerrit.libreoffice.org/72882Reviewed-by:
-
DaeHyun Sung yazdı
Modified Line Break Rule (Korean: 금칙 처리, 漢字hanja: 禁飭處理) I modifed Forbidden Characters(Korean: 금칙 문자, 漢字hanja: 禁飭文字) on LibreOffice Korean locale data xml. Reference1: HWP Guide - 금칙문자(Forbidden Characters) http://help.hancom.com/hoffice/webhelp/9.0/ko_kr/hshow/tool/forbid.htm Reference2: OOXML ISO/IEC 29500–1:2016(E) Korean * Cannot start a line: !%),.:;?]}¢°'"′″℃〉》」』】〕！％），．：；？］｝￠ (Unicode character values: U+0021, U+0025, U+0029, U+002C, U+002E, U+003A, U+003B, U+003F, U+005D, U+007D, U+00A2, U+00B0, U+2019, U+201D, U+2032, U+2033, U+2103, U+3009, U+300B, U+300D, U+300F, U+3011, U+3015, U+FF01, U+FF05, U+FF09, U+FF0C, U+FF0E, U+FF1A, U+FF1B, U+FF1F, U+FF3D, U+FF5D and U+FFE0, respectively) * Cannot end a line: $([\{£¥'"〈《「『【〔＄（［｛￡￥￦ (Unicode character values: U+0024, U+0028, U+005B, U+005C, U+007B, U+00A3, U+00A5, U+2018, U+201C, U+3008, U+300A, U+300C, U+300E, U+3010, U+3014, U+FF04, U+FF08, U+FF3B, U+FF5B, U+FFE1, U+FFE5, and U+FFE6, respectively) Change-Id: I32077b241f930cc912d0c365fc46c1cd046c59a6 Reviewed-on: https://gerrit.libreoffice.org/72492 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
also with the paragraph mark, not leaving an empty paragraph at the original place of the moved text. Note: as desktop version of MSO does, but its online version leaves empty paragraphs interestingly. Change-Id: I03dda8997df3efbc82e936bd31a3813323e6b5ab Reviewed-on: https://gerrit.libreoffice.org/71382Reviewed-by:
László Németh <nemeth@numbertext.org> Tested-by:
-
Jan-Marek Glogowski yazdı
Actually really evaluate some of the formating provided by the QInputMethodEvent::TextFormat attribute and not blindly underline all of the text. This evaluates the same formating that the gtk3 backend evaluates from pango, so the result should be somehow on par. Couldn't find a way to test the red strike-out text. Don't know how often I typed hyoujunnsutairu to test this bug, which - according to Google - translates to "standard style". Reviewed-on: https://gerrit.libreoffice.org/71783 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
As discussed in ESC call of 2019-02-21, enable kde5 for the Jenkins CI builds to detect build issues *before* the changes get merged. Reviewed-on: https://gerrit.libreoffice.org/68165 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
The utility constructor using 'StockImage::Yes' was only introduced in master commit 0f104bf3 and is therefore not available in libreoffice-6-2 branch. Build was therefore broken by commit f10c1c64 ("tdf#123549 Qt5 implement Qt5Menu::ShowCloseButton"), which first went unnoticed since qt5/kde5 wasn't enabled for CI builds on branch libreoffice-6-2. (This will be changed by https://gerrit.libreoffice.org/#/c/72741/ .) Also, add a missing include that lead to kde5-enabled CI builds failing [1], which I couldn't reproduce locally ("shell/source/backends/kde5be/kde5backend.cxx:190:5: error: ‘unique_ptr’ is not a member of ‘std’"). And fix more issues showing up in [2] and follow-up builds of the change that enables kde5 on the 6.2 branch [3]. [1] https://ci.libreoffice.org/job/gerrit_62/1535/ [2] https://ci.libreoffice.org/job/gerrit_62/1540/ [3] https://gerrit.libreoffice.org/#/c/72741/ Change-Id: I6a39a99114d15808b790242c96d0204916a0cc40 Reviewed-on: https://gerrit.libreoffice.org/72779Reviewed-by:
-
- 23 May, 2019 4 kayıt (commit)
-
-
Caolán McNamara yazdı
see also tdf#40457, tdf#115032 Change-Id: I505c3dfaf8f0a23e525db015f52a881b22016d11 Reviewed-on: https://gerrit.libreoffice.org/72847Reviewed-by:
-
Katarina Behrens yazdı
after many trials and errors what LibO apparently expects here is the ID of QWindow parent of [embedded] system child window (the rest of the original commit bbe1ede0 is not relevant for LibO 6.2) Change-Id: Ie4c6d14a50959c0fdd04e745918d4889c9da45ec Reviewed-on: https://gerrit.libreoffice.org/72458 Tested-by: Jenkins Reviewed-by:
-
Christian Lohmaier yazdı
Change-Id: I363a02d7115ea54bb4aedb38071a249e145ee471 Reviewed-on: https://gerrit.libreoffice.org/72742 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
The remaining problem is that with the previous commit, the layout stops at some point and everything is crammed into the next-to-last page, with the following symptom: warn:legacy.osl:7667:7667:sw/source/core/layout/tabfrm.cxx:2642: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910 This is apparently because of some very funny recursion that goes in circles until it formats some part of the "outer" table again. 0 SwTabFrame::MakeAll(OutputDevice*) (this=0x82b0280) at tabfrm.cxx:2642 ^ mpUpper -> 928 - top-level SwTabFrame and m_pFollow of 905 1 SwFrame::PrepareMake(OutputDevice*) (this=0x82b0280) at calcmove.cxx:372 2 SwFrame::Calc(OutputDevice*) const (this=0x82b0280) at trvlfrm.cxx:1790 3 SwFrame::PrepareMake(OutputDevice*) (this=0x6c06ba0) at calcmove.cxx:247 4 SwFrame::Calc(OutputDevice*) const (this=0x6c06ba0) at trvlfrm.cxx:1790 5 SwFrame::PrepareMake(OutputDevice*) (this=0x82aebf0) at calcmove.cxx:247 6 SwFrame::Calc(OutputDevice*) const (this=0x82aebf0) at trvlfrm.cxx:1790 7 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:247 8 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790 ^ m_pFollow->mpNext -> 332 - again! it's now m_pFollow->mpNext 9 SwTabFrame::MakeAll(OutputDevice*) (this=0x6d64570) at tabfrm.cxx:2544 ^ 303 - nested SwTabFrame, used to precede 332 but has now split and its m_pFollow precedes 332 10 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:313 11 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790 ^ 332 - SwTextFrame originally inside 991, but moved under top-level SwTabFrame 928 at this point 12 SwContentFrame::CalcLowers(SwLayoutFrame*, SwLayoutFrame const*, long, bool) (pLay=0x6dccbf0, pDontLeave=0x6ed6e30, nBottom=9223372036854775807, bSkipRowSpanCells=true) at tabfrm.cxx:1479 ^ m_pLower -> 991 - SwRowFrame 13 lcl_RecalcRow(SwRowFrame*, long) (pRow=0x6dccbf0, nBottom=9223372036854775807) at tabfrm.cxx:1614 14 lcl_RecalcTable(SwTabFrame&, SwLayoutFrame*, SwLayNotify&) (rTab=..., pFirstRow=0x6dccbf0, rNotify=...) at tabfrm.cxx:1691 15 SwTabFrame::MakeAll(OutputDevice*) (this=0x6ed6e30) at tabfrm.cxx:2082 ^ m_pFollow -> 905 - top-level SwTabFrame 16 SwTabFrame::MakeAll(OutputDevice*) (this=0x381d3e0) at tabfrm.cxx:2504 17 SwFrame::PrepareMake(OutputDevice*) (this=0x381d3e0) at calcmove.cxx:372 18 SwFrame::Calc(OutputDevice*) const (this=0x381d3e0) at trvlfrm.cxx:1790 ^ 866 - top-level SwTabFrame 19 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7fff95aa3f20, pTab=0x381d3e0, bAddRect=true) at layact.cxx:1483 20 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6cfedc0, bAddRect=true) at layact.cxx:1375 21 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6e23fd0, bAddRect=true) at layact.cxx:1380 The first attempt was to add a TextFrameLockGuard around the pFrame->MakeAll() call in PrepareMake(), with corresponding test in SwTabFrame::MakeAll() ... but a similar problem still occurred, just now on page 18 instead of page 12. Another idea is to prevent PrepareMake() from formatting the SwTableFrame's follow *again*; it was already formatted by SwTabFrame::MakeAll() anyway, just before it calls pNxt->Calc(). With this, we get 23 pages for the bugdoc, same as before that commit: (regression from 18765b9f) Change-Id: I71e3f92b5f19b800626a008527fa75d08641e8de Reviewed-on: https://gerrit.libreoffice.org/72799Reviewed-by:
-
