- 09 May, 2019 34 kayıt (commit)
-
-
Rizal Muttaqin yazdı
Change-Id: I22d811a89f0e024e99cccffc0c05b373e2820140 Reviewed-on: https://gerrit.libreoffice.org/72022 Tested-by: Jenkins Reviewed-by:
Rizal Muttaqin <riz_17_oke@yahoo.co.id>
-
Stephan Bergmann yazdı
Using g_main_loop_run here appears to be inherently necessary for the g_file_mount_enclosing_volume/g_file_mount_enclosing_volume_finish protocol, but has at least two problems: For one, it temporarily drops the SolarMutex (if it was held by the current thread), causing the usual integrity issues caused by an inner stack frame temporarily releasing the SolarMutex that is held by some unsuspecting caller. This is an inherent problem of our broken SolarMutex design, and this change can't do much about it. But for another, at least with GTK-based VCL backends, it also means that the current thread can start to execute VCL events at "unexpected" times from within this g_main_loop_run (e.g., paint events, as in the backtraces linked from tdf#124962). While handling of VCL events is necessary when a callback to ooo_mount_operation_ask_password happens and it actually pops up a dialog prompting the user for credentials, such handling of VCL events is completely unwanted when no such dialog is popped up (e.g., when the given server is unreachable anyway, as is the case in tdf#124962). So, to shrink the problematic window of time in which VCL events may get handled from within the gio MountOperation, use a dedicated GMainContext for the gio GMainLoop (so that it only handles events related to the mount operation), and only temporarily put back in place the original GMainContext during ooo_mount_operation_ask_password (so that VCL events will get handled as necessary when a dialog is actually popped up). Change-Id: Ie410f23778045b1adf98579bb34ce38d0f8f3320 Reviewed-on: https://gerrit.libreoffice.org/72026 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com>
-
Noel Grandin yazdı
Change-Id: I8dc5a6ef84f43bad0bee26592b3a8e95c58e6f22 Reviewed-on: https://gerrit.libreoffice.org/72027 Tested-by: Jenkins Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
Noel Grandin yazdı
Change-Id: I1fa8248efa16a718f273f20620281737b0da455d Reviewed-on: https://gerrit.libreoffice.org/72024 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
with dynamic columns Change-Id: I1f2ed918932066d8b0def57568f5dc23be3605e4 Reviewed-on: https://gerrit.libreoffice.org/72028 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Tomoyuki Kubota yazdı
Doxygen used to allow this but there was a regression, which is apparently not being fixed: https://github.com/doxygen/doxygen/issues/6304 Change-Id: I7602236522a56c30a2249bd8065796b3c6458704 Reviewed-on: https://gerrit.libreoffice.org/70377Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> Tested-by:
-
Jens Carl yazdı
Change-Id: Iafbb69a405a3c9ee8d0ae7dbe8a24a75d237519d Reviewed-on: https://gerrit.libreoffice.org/71924 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
Change-Id: I337c0f567112f95e2a1d762e511d5b632dd2892f Reviewed-on: https://gerrit.libreoffice.org/71997 Tested-by: Jenkins Reviewed-by:
Luboš Luňák <l.lunak@collabora.com>
-
Gabor Kelemen yazdı
As seen in tools/source/misc/cpuid.cxx Change-Id: Ic596cca387efc1c310f65cbed141946be0742371 Reviewed-on: https://gerrit.libreoffice.org/71885 Tested-by: Jenkins Reviewed-by:
-
Gabor Kelemen yazdı
As seen in configmgr/source/modifications.hxx and configmgr/source/partial.hxx this replacement is not needed Change-Id: I6a8d7bc37779f305fccb5d3c7df22fba4a4f73d0 Reviewed-on: https://gerrit.libreoffice.org/72013 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
This avoids the preprocessing step normally done by ccache (see ccache docs), which speeds up the build. This way there may be incorrect ccache hits if a system header (found using -isystem) changes, but that should be rare and such headers generally should be backwards compatible, so the chance of an actual breakage should be very low. The patch also adds --enable-ccache=nodepend to allow enabling ccache without the depend mode. https://lists.freedesktop.org/archives/libreoffice/2019-May/082684.html Change-Id: Id69ca43988a016a917beb75927b39d8bde719aa7 Reviewed-on: https://gerrit.libreoffice.org/71629 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
So that it works out of the box automagically. Change-Id: I0a6c93824233eef6ce25c44762ec40770ec5110f Reviewed-on: https://gerrit.libreoffice.org/71628 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
It a) looked a bit silly to use .gch even with MSVC, b) allows to build something with Clang and GCC without them trying to use each other's PCH file, c) is nitpicking, yeah. Change-Id: I478beeb6aab6378cbdcc6ea75aa2e3ff2bcf6f87 Reviewed-on: https://gerrit.libreoffice.org/71582 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
Plus some build fixes triggered by this. Change-Id: I59b21def706598ceffd45ae5b1f0262ec9c1ad50 Reviewed-on: https://gerrit.libreoffice.org/71581 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
There are now 4 levels of PCH support, the previous 'full' level adding to PCH whatever the update_pch script finds useful, and new levels 'system', which adds only external headers, 'base', which is 'system' and LO basic headers (sal, osl, rtl, vcl) and 'normal', which is 'full' without headers from the module built itself. With Clang/GCC even 'system' still saves some time (10-15%) and since external headers should rarely if even change, it should be without most of the disadvantages of PCH. And even 'base' should be pretty easy to use, as those headers should be rarely changed while developing, thus avoiding the need for massive rebuilds. Using 'normal' or 'full' does not seem to be worth it with Clang or GCC, but with MSVC that still makes a difference, so keep(?) 'full' the default there. The update_pch script unfortunately does not include as many system headers as it could, since it includes only what is directly included by the .cxx, but not what's included indirectly by .hxx files. https://lists.freedesktop.org/archives/libreoffice/2019-May/082685.html Change-Id: If83a07a1fc9b77d0134502b0d89348944f82806b Reviewed-on: https://gerrit.libreoffice.org/71580 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
config_xxx.h headers are not system headers, and some module headers as such helpids.h or scdllapi.h are neither. Change-Id: I7ae1a3f1ada43de88eefe34c60e19f7ac703769d Reviewed-on: https://gerrit.libreoffice.org/71579 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
Change-Id: I52ef8e81cb3899cc8d2b8729bd55ee98a0a1c77b Reviewed-on: https://gerrit.libreoffice.org/71565 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
The problem is that the SwTabFrame and SwRowFrame that are being iterated are deleted: 7 SwFrame::DestroyFrame(SwFrame*) (pFrame=0x79052c0) at sw/source/core/layout/ssfrm.cxx:386 8 SwTabFrame::RemoveFollowFlowLine() (this=0x5bf07d0) at sw/source/core/layout/tabfrm.cxx:907 9 SwTabFrame::MakeAll(OutputDevice*) (this=0x5bf07d0) at sw/source/core/layout/tabfrm.cxx:1839 10 SwFrame::PrepareMake(OutputDevice*) (this=0x5bf07d0) at sw/source/core/layout/calcmove.cxx:344 11 SwFrame::Calc(OutputDevice*) const (this=0x5bf07d0) at sw/source/core/layout/trvlfrm.cxx:1790 12 SwFrame::PrepareMake(OutputDevice*) (this=0x603a570) at sw/source/core/layout/calcmove.cxx:247 13 SwFrame::Calc(OutputDevice*) const (this=0x603a570) at sw/source/core/layout/trvlfrm.cxx:1790 14 SwFrame::PrepareMake(OutputDevice*) (this=0x5daf120) at sw/source/core/layout/calcmove.cxx:247 15 SwFrame::Calc(OutputDevice*) const (this=0x5daf120) at sw/source/core/layout/trvlfrm.cxx:1790 16 SwFrame::PrepareMake(OutputDevice*) (this=0x6005ca0) at sw/source/core/layout/calcmove.cxx:247 17 SwFrame::Calc(OutputDevice*) const (this=0x6005ca0) at sw/source/core/layout/trvlfrm.cxx:1790 18 SwFrame::MakePos() (this=0x6094330) at sw/source/core/layout/calcmove.cxx:490 19 SwTextFrame::MakePos() (this=0x6094330) at sw/source/core/text/frmform.cxx:343 20 SwContentFrame::MakeAll(OutputDevice*) (this=0x6094330) at sw/source/core/layout/calcmove.cxx:1346 21 SwFrame::OptPrepareMake() (this=0x6094330) at sw/source/core/layout/calcmove.cxx:368 22 SwFrame::OptCalc() const (this=0x6094330) at sw/source/core/inc/frame.hxx:1060 23 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x8a349c0, bAddRect=false) at sw/source/core/layout/layact.cxx:1362 24 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x79052c0, bAddRect=false) at sw/source/core/layout/layact.cxx:1357 25 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7ffc6da48350, pTab=0x7a9c300, bAddRect=false) at sw/source/core/layout/layact.cxx:1569 26 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x7c30300, bAddRect=true) at sw/source/core/layout/layact.cxx:1354 27 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7ffc6da48350, pLay=0x79e1780, bAddRect=true) at sw/source/core/layout/layact.cxx:1357 28 SwLayAction::InternalAction(OutputDevice*) (this=0x7ffc6da48350) at sw/source/core/layout/layact.cxx:546 They are deleted because the last SwTextFrame was moved via MoveBwd() to the previous page, and is formatted there. (regression from commit 18765b9f) Prevent this via: * delete-guard for the SwRowFrame - causing RemoveFollowFlowLine() to return early (also, let it return false, so the Join() isn't even called, although that doesn't make a difference in practice because of the next item:) * join-guard for the SwTabFrame - otherwise tabfrm.cxx:2199 will Join() it anyway This means that when the page with the follow-frame is done formatting, the empty SwTabFrame with no SwTextFrame in it will remain. Fortunately this is not a problem, because due to the moving, the previous page will be invalid and layact.cxx:613 will iterate to the previous page and format it again; then tabfrm:2199 of the master SwTabFrame will detect that the follow SwTabFrame is empty and Join() it. Change-Id: I2cca89d63b81e7d4909319fa4feab2f5d67a6ff3 Reviewed-on: https://gerrit.libreoffice.org/71996 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
For one, it seems this was the intention already since commit 85c70f37 (CWS-TOOLING: integrate CWS aw063, 2009-03-04): "suppress AntiAliasing for pure horizontal or vertical lines". For another, this fixes the TileCacheTests::testTileWireIDHandling() testcase in online.git, which assumes that the indicators at the corners of the Writer body frame (paragraph marks hidden / default case) can be painted multiple times, producing pixel-by-pixel matching results. But in reality AA breaks that assumption, and we know these indicators are never diagonal lines. Change-Id: Ib74f823165799991296b64cee58ec106dbdcedcf Reviewed-on: https://gerrit.libreoffice.org/72000Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
-
Jan-Marek Glogowski yazdı
2nd attempt to fix the bug described in commit 00221089 ("Qt5 IM allow committing empty strings") and various siblings of it. This also reverts it. What I see is calls with "all-empty" events (preedit, commit and replacementLength() == 0; no QInputMethodEvent::Attribute), some from QIBusPlatformInputContext::updatePreeditText. There are various Writer document edit states with (selected) text, undo, cursor position and focus changes to other windows via Ctrl+Tab, which will result in inputMethodEvent calls totally in contrast to the expected text state, all somehow always related to all-empty events. They currently result in wrongly deleted selected text, change of selection, cursor movement or general change of text from old preedit. Most time on focus out / window change, some times at first meta-key press after focus in. This patch tries hard not to corrupt Writers edit state with these all-empty events. No idea if this is some bug on LO's qt5 side or expected, but KDE kate and VCL gtk3 and gen work fine, so I assume Qt's behaviour is correct. FWIW gtk3 also does some extended IM handling with focus, so probably this is the Qt equivalent of it. But then I couldn't find some eqivalent code in Qt's source code. I actually expected an even more complex solution (if this really fixes all cases). Works for a multitude of tests I tried to come up with, but is quite probably not the final fix to this, as qt5 current doesn't handle replacementStart() and replacementLength() at all. Also never saw a call to Qt5Frame::EndExtTextInput. Change-Id: I4210e0588041cfb4d80dbdfdb937e430a5f7cbfb Reviewed-on: https://gerrit.libreoffice.org/71988 Tested-by: Jenkins Reviewed-by:
Jan-Marek Glogowski <glogow@fbihome.de>
-
Justin Luth yazdı
Similar to bug 105625, the cursor should be considered outside of a fieldmark when it is at the start. A delete at the start would normally delete the entire form field, but in this case the section is supposed to be protected, so deleting should be forbidden. This atStart situation is already looked for when the document is not protected. However, when the section is already protected, then a different code path is followed, and there the start position was ignored and thus became an editable part of the page, allowing the user to easily delete the field by mistake. LO6.2's commit 63ec2e8d accurately identfied that this is in a protected section, and so exposed this missing scenario. Related idea: Also added a unit test to ensure that Protect_Form keeps protecting the formfields as well. A test document in the bug report, containing a combobox and checkbox, confirms that this fix is good for all three types of fieldmarks. Change-Id: Ida08163f3376e55c620d6670da160832e79cd252 Reviewed-on: https://gerrit.libreoffice.org/71927 Tested-by: Jenkins Reviewed-by:
Justin Luth <justin_luth@sil.org>
-
Jens Carl yazdı
Synchronize sub menu Tools > Macros by adding "Edit Macros" across the different applications menus. Change-Id: I16185034955d889afe8a508a3522bb0a63f29545 Reviewed-on: https://gerrit.libreoffice.org/71827Reviewed-by:
Heiko Tietze <tietze.heiko@gmail.com> Tested-by:
andreas_kainz <kainz.a@gmail.com>
-
Gabor Kelemen yazdı
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I89c77656ea4021cb16bd122cb1dd1cd803390c3d Reviewed-on: https://gerrit.libreoffice.org/71765 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
Change-Id: Ibe4ef82cf719afd008f1be23ed4a0e953c61d73f Reviewed-on: https://gerrit.libreoffice.org/72010 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I2b5827c3f6fd7630655d4658844792462f80767e Reviewed-on: https://gerrit.libreoffice.org/72016 Tested-by: Jenkins Reviewed-by:
Julien Nabet <serval2412@yahoo.fr>
-
Arkadiy Illarionov yazdı
Use range-based loops Change-Id: I4d3be75bb83c74267b9dec6f1dcdc105c292be9d Reviewed-on: https://gerrit.libreoffice.org/72011 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: I05c627f590e7794c1ba11b66021dc30aa3285eb0 Reviewed-on: https://gerrit.libreoffice.org/71941 Tested-by: Jenkins Reviewed-by:
-
Noel Grandin yazdı
Change-Id: If7f51a657606da8aea4bcf01f13468c6ac2086a8 Reviewed-on: https://gerrit.libreoffice.org/71901 Tested-by: Jenkins Reviewed-by:
-
Stephan Bergmann yazdı
...in preparation for another change using a top-level namespace ucb Change-Id: I3a92d64806bc570bdfd4fe06e672cb6ce2049e7e Reviewed-on: https://gerrit.libreoffice.org/71987 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I0c594c232a3004c83a33f0948593850dd924caad Reviewed-on: https://gerrit.libreoffice.org/72020Reviewed-by:
-
Tomaž Vajngerl yazdı
This is intended to replace the ImplPixelFormat in macOS and OpenGL backends, which are duplicated. It'll also come in handy for other situations in the future. Also ImplPixelFormat4 (4-bit Palette) in the macOS backend doesn't work and never has worked correctly (bug at writing). This fact was discovered while testing the ScanlineTranformer, which was based on the ImplPixelFormat* code. Change-Id: I96a172bd61c2cc116ab3e8b9f47f23f945243e96 Reviewed-on: https://gerrit.libreoffice.org/71992 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com>
-
Adrien Ollier yazdı
Change-Id: I4b4fc85024d64f94197bd0fd25ed8ba0ada004ba Signed-off-by:
Adrien Ollier <adr.ollier@hotmail.fr> Reviewed-on: https://gerrit.libreoffice.org/71807 Tested-by: Jenkins Reviewed-by:
-
Andrea Gelmini yazdı
Change-Id: I88a32792c19a8d16c400dd2a189c4941149ff941 Reviewed-on: https://gerrit.libreoffice.org/72019 Tested-by: Jenkins Reviewed-by:
Jens Carl <j.carl43@gmx.de>
-
Andrea Gelmini yazdı
Change-Id: I77133378411c573dd1075d40c7e113b305b3dbba Reviewed-on: https://gerrit.libreoffice.org/72017 Tested-by: Jenkins Reviewed-by:
-
- 08 May, 2019 6 kayıt (commit)
-
-
Stephan Bergmann yazdı
...after 7764439f "WidgetDefinition: add 'action' state for the PushButton" introduced code that downcasts that suspicious ImplControlValue to a PushButtonValue Change-Id: I3ed24cc4a862d53ad5b6e95b4707bab7947ce7ba Reviewed-on: https://gerrit.libreoffice.org/71998Reviewed-by:
-
Tomaž Vajngerl yazdı
Change-Id: Idfefe7598df0b2e382be84aa5bfc8b60201768a7 Reviewed-on: https://gerrit.libreoffice.org/71991 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
e.g fdo58094-1.mml since... commit 13894996 Date: Sat May 4 21:46:31 2019 +0200 handle empty Rectangle better in starmath Change-Id: I01d11352b8bc9f6dcf6d6565fa41b84d549f620f Reviewed-on: https://gerrit.libreoffice.org/71963 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I66db4b9f800eb2e3e0b81d4e8f9c2b7f742d23cf Reviewed-on: https://gerrit.libreoffice.org/71953 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: Ia29abf667b1d010692e89b3b8c23614a4b345669 Reviewed-on: https://gerrit.libreoffice.org/71962 Tested-by: Jenkins Reviewed-by:
-
Gabor Kelemen yazdı
As seen in sw/source/core/inc/layact.hxx Change-Id: Icc4281cd57b0cd8310a1044f6106691a5d1cd3c4 Reviewed-on: https://gerrit.libreoffice.org/71884 Tested-by: Jenkins Reviewed-by:
-
