- 23 May, 2019 33 kayıt (commit)
-
-
Caolán McNamara yazdı
Change-Id: I340b1695588bea0f1ce15685731c522907fdb7ee Reviewed-on: https://gerrit.libreoffice.org/72806 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
-
Caolán McNamara yazdı
Change-Id: I658773f4fc0409a73de56301f5457fa1fb9e4a28 Reviewed-on: https://gerrit.libreoffice.org/72805 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I9c348e34a07ab269217f35633cb3a54ea4f7cf68 Reviewed-on: https://gerrit.libreoffice.org/72804Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I6d4aca59d5f9e24521876c36853b663b65a2d200 Reviewed-on: https://gerrit.libreoffice.org/72803 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I93f3dccb1aac4a018f5a5dd7af61024306099675 Reviewed-on: https://gerrit.libreoffice.org/72802Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I055f01d2ce462009986801d4a603b0b72b1a621c Reviewed-on: https://gerrit.libreoffice.org/72787 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
otherwise the IMapWnd and CountourWindow don't accept the double-click release as finishing polygon editing Change-Id: Iaab7a46cad2c5c92fdc2f8ff61135792fae67be8 Reviewed-on: https://gerrit.libreoffice.org/72830 Tested-by: Jenkins Reviewed-by:
-
Stephan Bergmann yazdı
But some of those functions' names may be more telling than their configuration property counterparts, so there may be merit in keeping those trivial wrapper functions around. Change-Id: Ibbf4965fcefd58649920fad964b4a8d2108deaca Reviewed-on: https://gerrit.libreoffice.org/72836 Tested-by: Jenkins Reviewed-by:
Stephan Bergmann <sbergman@redhat.com>
-
Stephan Bergmann yazdı
...as it does the same as the copy assignment op. And both of those are apparently already only called with SolarMutex locked, so no need to lock it again. So the copy assignment op (as well as the other special memeber functions) can be left implicitly-declared. (And some uses of the original takeOver can be optimized to use move assignment.) Change-Id: I279a5e3ee85ff2342d6ef5f672108a0712fe116d Reviewed-on: https://gerrit.libreoffice.org/72831 Tested-by: Jenkins Reviewed-by:
-
Olivier Hallot yazdı
* Update helpcontent2 from branch 'master' - Untangle Help Contents for Impress and Draw Create a separated sdraw.tree for Contents and move entries from Impress tree to Draw tree. Common contents are maintained in both trees. This is work in progress. Draw and Impress Help pages need update especially for menus. Change-Id: I179a5ee7407c4a8357a87b2e7a0d8782b7bb0520 Reviewed-on: https://gerrit.libreoffice.org/72693 Tested-by: Jenkins Reviewed-by:Olivier Hallot <olivier.hallot@libreoffice.org>
-
Stephan Bergmann yazdı
(but even better to actually use move assignment op) Change-Id: I6d9c4a9568ef03d84b7acd48a129d0c723c915cb Reviewed-on: https://gerrit.libreoffice.org/72820 Tested-by: Jenkins Reviewed-by:
-
Muhammet Kara yazdı
As per ESC & Design Team decisions. It has become unusable anyway after major changes on the Mozilla side. Long live Libreoffice Themes! :) Change-Id: I2893fbc5e4f5637ee9715fa426b92ca58534f126 Reviewed-on: https://gerrit.libreoffice.org/72811 Tested-by: Jenkins Reviewed-by:
Julien Nabet <serval2412@yahoo.fr> Reviewed-by:
Heiko Tietze <tietze.heiko@gmail.com> Reviewed-by:
Muhammet Kara <muhammet.kara@collabora.com>
-
Miklos Vajna yazdı
Which allows not hardcoding true for LOK. Change-Id: I644763ba052b148fc34283e361aa02f9bba2c5ee Reviewed-on: https://gerrit.libreoffice.org/72832Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Tested-by:
Michael Meeks <michael.meeks@collabora.com>
-
Rizal Muttaqin yazdı
Change-Id: I3ecaea025fda7a4808f76a9ccda218225ddd38bd Reviewed-on: https://gerrit.libreoffice.org/72808 Tested-by: Jenkins Reviewed-by:
Rizal Muttaqin <riz_17_oke@yahoo.co.id>
-
Christian Lohmaier yazdı
Change-Id: I363a02d7115ea54bb4aedb38071a249e145ee471 Reviewed-on: https://gerrit.libreoffice.org/72742 Tested-by: Jenkins Reviewed-by:
Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
-
Noel Grandin yazdı
sooner or later someone is going to need more than 65535 redlines Change-Id: I34a913a0beaac14b64b58964ace022210a8eac40 Reviewed-on: https://gerrit.libreoffice.org/72773 Tested-by: Jenkins Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
Noel Grandin yazdı
and move the auto-format embedded flag to a separate field Change-Id: I02155702389178fbfdf874f592d47a29f8759974 Reviewed-on: https://gerrit.libreoffice.org/72771 Tested-by: Jenkins Reviewed-by:
-
Luboš Luňák yazdı
Its PCHs are always different even if the source is the same (timestamps somewhere?). But if the output of gcc -E for that precompiled header source is the same, then technically the .gch should be without a change. So this makes ccache get hits even if the .gch gets rebuilt, as long as ccache is new enough to support CCACHE_PCH_EXTSUM (3.5+). Change-Id: I447bb4840047f23deed55e25de1794047a0a9998 Reviewed-on: https://gerrit.libreoffice.org/72705 Tested-by: Jenkins Reviewed-by:
Luboš Luňák <l.lunak@collabora.com>
-
Michael Stahl yazdı
It's ridiculously un-cooperative, and if you accidentally run the script from a static IP you won't be able to look at that bugzilla for a while, which is tragic because it holds important historical info hostage. Change-Id: I55887baceac82ad0a3bcedc3de9c9b3d0e02f9c3 Reviewed-on: https://gerrit.libreoffice.org/72220 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de>
-
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:
-
Michael Stahl yazdı
This is some copypasta, apply the same fix. Change-Id: I096594f6d54fef68e63c982c2963499d24af6d15 Reviewed-on: https://gerrit.libreoffice.org/72798 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
The problem is that with the change in SwFlowFrame::MoveBwd(), a SwTextFrame in a table may move backwards during MakeAll(); if the next frame of the moved frame, and the "this" frame in PrepareMake(), is a SwTabFrame, then the pFrame->FindNext() will return not this SwTabFrame, but the first SwTextFrame *inside* the SwTabFrame - hence the iteration will never meet the "pFrame == this" termination condition and the SwTabFrame remains unformatted; this warning is printed: warn:legacy.osl:6874:6874:sw/source/core/layout/calcmove.cxx:296: :-( Layout unstable (this not found). (regression from 18765b9f) Change-Id: I68207ba9cf68cd5abe51d647cb757176261eda40 Reviewed-on: https://gerrit.libreoffice.org/72797 Tested-by: Jenkins Reviewed-by:
-
Gülşah Köse yazdı
Change-Id: I898fb0830a9f53da4a7917cb5900f082e3a9d6b7 Reviewed-on: https://gerrit.libreoffice.org/71944 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: Ic5cb575189984246365d8a1067e61ea84eaa5dce Reviewed-on: https://gerrit.libreoffice.org/72768 Tested-by: Jenkins Reviewed-by:
-
andreas kainz yazdı
Change-Id: I67b76b65105e5020ea396ab68d41999c80368c41 Reviewed-on: https://gerrit.libreoffice.org/72812 Tested-by: Jenkins Reviewed-by:
andreas_kainz <kainz.a@gmail.com>
-
Grzegorz Araminowicz yazdı
Change-Id: I6d44335ab51c92dc605ee341efaaa4bf6f7bd42f Reviewed-on: https://gerrit.libreoffice.org/72587 Tested-by: Jenkins Reviewed-by:
-
Gabor Kelemen yazdı
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I23a6d485ee1ca0bc3801bcc1a6d748b8ed2b490c Reviewed-on: https://gerrit.libreoffice.org/72634 Tested-by: Jenkins Reviewed-by:
-
Miklos Vajna yazdı
Change-Id: I677c3b184e225c3bac1c56efd5ea46aaa2497d69 Reviewed-on: https://gerrit.libreoffice.org/72810 Tested-by: Jenkins Reviewed-by:
-
brinzing yazdı
Property "PickListEntry" is available since LO 5.1 but not mentioned in css.document.MediaDescriptor. original change has been committed with tdf#95095. Change-Id: I684e4c76f79c9646af3cac9670790d2b2c3eca97 Reviewed-on: https://gerrit.libreoffice.org/72553 Tested-by: Jenkins Reviewed-by:
-
Tor Lillqvist yazdı
This is for COLEAT's internal use. Change-Id: If1ac2a5b251129e4431d3c0bde82529d6bdc7ccc Reviewed-on: https://gerrit.libreoffice.org/72809 Tested-by: Jenkins Reviewed-by:
Tor Lillqvist <tml@collabora.com>
-
Jan-Marek Glogowski yazdı
The page handling implementation is a little bit tricky, because the elemnt list is not handled like a grid but a list. Normally one would keep the horizontal cell and just scroll vertically. Instead this implements a kind of circle. Vertical offset is consistet, so you have the same amount of steps for up and down, but up runs left and down runs right. Change-Id: I296a46e98f7e00a59fd0a0ba358c981b49ac86cd Reviewed-on: https://gerrit.libreoffice.org/72793 Tested-by: Jenkins Reviewed-by:
Jan-Marek Glogowski <glogow@fbihome.de>
-
Jan-Marek Glogowski yazdı
This adds arrows + home + end key navigation. The grid is handled like a list. For convenience Left + Up and Right + Down keys work in the same way. Change-Id: I757184e5161f2c7ac9b241294a5edc304c882497 Reviewed-on: https://gerrit.libreoffice.org/72792 Tested-by: Jenkins Reviewed-by:
-
Jan-Marek Glogowski yazdı
Just implements Move the same way then Resize. More importantly the patch correctly resets the Thumb and Page rectangles to position (0,0) instead of just Empty, which ImplCalc is based on. Otherwise this results in broken scroll bars, when the StarMath elements window is docked in in the bottom or top area and switches the scrolling orientation on undock. Change-Id: I32b0507cdd6551cc7f42655a730faf8ef25b747b Reviewed-on: https://gerrit.libreoffice.org/72794 Tested-by: Jenkins Reviewed-by:
-
- 22 May, 2019 7 kayıt (commit)
-
-
Jan-Marek Glogowski yazdı
Switches the ScrollBar to horizontal in vertical mode and adapts the scrolling. Change-Id: I35370d74175ccd1f117b17f7d7ffa25119f2e612 Reviewed-on: https://gerrit.libreoffice.org/72791 Tested-by: Jenkins Reviewed-by:
-
Jan-Marek Glogowski yazdı
Moves duplicate code from ImplInitSettings and ApplySettings into their own functions. Change-Id: I65b5a052b171a661ee22762e373745c28779a9e9 Reviewed-on: https://gerrit.libreoffice.org/72790 Tested-by: Jenkins Reviewed-by:
-
Jan-Marek Glogowski yazdı
Replaces some code with calls to ApplyControlForeground and ApplyControlFont. Change-Id: I16837ad7c48ed46fa48b1f2a33a84c7e94f63482 Reviewed-on: https://gerrit.libreoffice.org/72789 Tested-by: Jenkins Reviewed-by:
-
Jan-Marek Glogowski yazdı
TextEngine::SetFont copies the font parameter and then modifies its color, transparency, fill color and alignment, so passing the same font again will not be detected as the same font. Therefore this patch stores the original font in addition to the modified one and also returns that one on the GetFont call. This allows us to merge the font setup in VclMultiLineEdit's ImplInitSettings and ApplySettings into a common function. Change-Id: I618d283ecd0ae14faf9b87a3aceec6ca1c37b526 Reviewed-on: https://gerrit.libreoffice.org/72788 Tested-by: Jenkins Reviewed-by:
-
Xisco Fauli yazdı
Change-Id: I221b7ae202d6dbd08d0496561652b2471b093b46 Reviewed-on: https://gerrit.libreoffice.org/72783Reviewed-by:
Xisco Faulí <xiscofauli@libreoffice.org>
-
Miklos Vajna yazdı
Regression from commit 458a827e (further refactor Menu to use RenderContext, 2015-05-15), the problem was that this highlight on the menu bar on mouse move was only part of the incremental paint, never the full paint. So when that commit removed incremental paint, we lost highlight on mouse move (move only, click is there). Later commit 843b9d5d (VCL add support for rollover menubars, 2016-09-22) added this code back, conditionally for the case when there is not enough space for the menu bar horizontally. So fix the lack of highlight on plain mouse move by unconditionally highlighting the rolled over item, even if there is enough horizontal space. Change-Id: I357001f2e65f843444ed0ffbe470667dfc5d5aa3 Reviewed-on: https://gerrit.libreoffice.org/72774Reviewed-by:
-
Xisco Fauli yazdı
Change-Id: I2080f3c04a04cea626d4969b59e54612cbefe03b Reviewed-on: https://gerrit.libreoffice.org/72780Reviewed-by:
-
