Age | Commit message (Collapse) | Author |
|
...to "Find functions that take rtl::O[U]String parameters that can be
generalized to take std::[u16]string_view instead." (Which in turn can avoid
costly O[U]String constructions, see e.g. loplugin:stringview and subView.)
Some of those functions' call sites, passing plain char string literals, needed
to be adapted when converting them.
Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This reverts commit 48b667a7e7d25f835f95df89162a7849d6972531.
Reason for revert: some discussion required
Change-Id: Ia0990d280837fb68b7ddc9f472ec78b1467b4311
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105540
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
A text box and its including shape are now going to keep their
positions in sync along the horizontal (X) axis as well as the
vertical (Y) axis.
Moreover, Shift-UpArrow, Shift-DownArrow, Shift-LeftArrow and
Shift-RightArrow are all going to work the same as the plain
arrow keys, they are just going to move the text a larger
distance.
Change-Id: I49482a101d97927715f47efbf0f58808ea6a8547
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105328
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ic2833f2e6dfea4a9e3dd1094151f86e07be83040
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105623
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Pie chart legend changed when VaryColorsByPoint was false.
Change-Id: I8022e5290f2269a902b4417f91d2e454f088c553
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105172
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
The 'normal' anchor (as on screen) is connected to the snap rectangle,
the NoRotatedAnchor is connected to the logic rectangle. They differ,
if the shape is transformed, e.g. rotated. Error was, that values of
the 'normal' anchor were applied to NoRotatedAnchor instead of
calculating the shift of NoRotatedAnchor independently. The error
becomes only visible on save, because there the NoRotatedAnchor is
used. Effected shape types are legacy shapes, text boxes and
transformable OLEs.
I have not tested, whether this fix would work for LO 7.0 too.
Change-Id: I8ad22ca54bdd49861a16a34736860a9871d8eba0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105611
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This causes interference to other views due to usage
of global references in Online.
Change-Id: Ib9346881d4e48ac1ce3456d386806582ade82255
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103994
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105593
Tested-by: Jenkins
|
|
Change-Id: I04243667b564670096d2c8db0352ab179e1b0151
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104212
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105595
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
This patch is based on testing results, since I couldn't find anything
in the documentation that indicated a change between Word 2010
and Word 2013. But the evidence is fairly clear I think.
To quote from MS documentation on relativeHeight:
> This attribute shall only indicate the Z-order with respect to other objects
> in the document which have an identical behindDoc attribute value.
> _All_ objects with a behindDoc value of false shall be displayed
> above elements with a value of true.
But only wrapNone makes mention of being affected by behindDoc,
so apparently MS decided to ignore it for some reason starting
in Word 2013. By simply changing the compatibiltyMode value to
one lower, Word 2013 again starts to honour the behindDoc setting.
Change-Id: I7ef40387707ab5376cf8fa4d8a208c5b6a8b37ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105486
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I963aa5fb892a0be36212fd0587b69f217f017947
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105469
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
use an expander for the expander-like feature
Change-Id: I3af63dc252479914a0000aab59a30744f8073fd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105310
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I46556c7242ad9b5c4c7a8fb923dc87458e56494e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105613
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
merge them together to form a single checkbox, so clicking the label
toggles the checkbox on/off.
Change-Id: I156aadc99444bcbadbc8b86a26426781fb07b660
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105598
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Idd8901225ddb687a2d1b8b5ba4069b40f218191f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105603
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7733cdb2bbed8e39dbbafd63b360513ab9ad5e6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105612
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
All the needed API is already in the version we bundle, except one. And
also we'll need direct access to the underling pdfium document, for now.
Change-Id: Ib5c87c95072401b1a6ca0151177d70b4bcd8c46d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105610
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
UNO dialogs since LibreOffice 4.0 permitted setting HScroll /
VScroll properties to enable scrolling for too large a content.
Conceptually clone this code over to TabPage as well, and register
necessary UNO properties in the toolkit UNO wrappers.
Add missing API documentation also to UnoControlDialogModel,
plus the new properties to the UnoControlTabPageModel
Layout code really doesn't like any extra controls it didn't create
itself - so create scrollbars only on demand.
Change-Id: I67894597ac104320e67ad7989ebf9a7955d99103
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105573
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I94b624f5340709e2cc456be12c7b21eab508dddb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105609
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie3a6db501328e787d7b87dfd1aef73d9d79a49ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105608
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Whatever the reason was for the
<https://bz.apache.org/ooo/show_bug.cgi?id=111186> "sw/qa/unoapi
sw.PageStyle::com::sun::star::beans::XPropertySet::setPropertyValue() failure"
> 21: LOG> Execute: setPropertyValue()
> 21: LOG> starting required method: getPropertySetInfo()
> 21: LOG> try to cheange value of property 'FootnoteLineWeight'
> 21: Method setPropertyValue() finished with state FAILED
> 21: LOG> setPropertyValue(): PASSED.FAILED
failure, it appears to work fine now in JunitTest_sw_unoapi_1.
Change-Id: I205c0e39e5a6ce6b5793eb52687e631d31936789
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105604
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that is apparently unused ever since the code's introduction in
c6f950665971100ff2e51cf7e05d30141e8e89e1 "INTEGRATION: CWS taskpane"
Change-Id: Ie80eb9ad710fe2653b79015aa5c18e619944340f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105600
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
In online we can have users with multiple languages.
Select style in sidebar depending on translated name
and also universal/English.
Change-Id: Ia33df29526e5fd8de5c7e0f7f6f74e0b0f559477
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103000
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105592
Tested-by: Jenkins
|
|
which was introduced in
commit adf0738d2dbfa742d0e9ef130954fb4638a8e90d
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Jan 3 14:25:15 2018 +0200
long->sal_Int32 in BigInt
presumably to make the conversion easier.
Instead just fix the call-sites to select a better
conversion, BigInt only returns 32-bits of precision
anyway.
Change-Id: I2e4354bcfded01763fe3312a715ef37800297876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105602
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which was added in
commit 331e2e5ed3bf4e0b2c1fab3b7bca836170317827
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Sep 14 08:49:52 2017 +0200
long->sal_Int32 in Fraction
presumably to make the change impact less code.
Instead, update the call sites to reflect the actual bitwidth
of the data we will be receiving.
Change-Id: If2a678b1cf534f39cb8cb249757462be53658309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105607
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8b36fd0dde6f4e7f83cf73dc8b6aefb196babb8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105571
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
|
|
Change-Id: I1da6cd45c5039f2b36ae6d8a64febc69eda9c6d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105569
Tested-by: Jenkins
Reviewed-by: Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>
|
|
... when we also have an SwUserField.
The problem is that a DocVariable gets imported as an SwUserField, but
then SwDocUpdateField::InsertFieldType() marks the field as dirty.
This causes IsFieldsDirty() to return true, so then
DocumentTimerManager::GetNextIdleJob() decides to recalc all fields.
This leads to loosing the cached result of conditional fields.
Change-Id: I4f5c032648f8fc2aff98e4f8c883492375c7752d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105596
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Previously, only Lookup method called parsing correctly, taking
into account that the object is in its own stream and has its
own elements vector. Many other methods called parse with the
wrong - document element vector. This changes the code so that
a common method is called in all instances with the correct
elements vector as the input parameter.
Change-Id: I7092f7ce683f07065da15cfa548b06c019efeed4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105491
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Objects can be stored in a compressed stream inside a PDF stream,
so we can't assume that we always copy from a document stream, but
we need to check if we have an object stream available and use
that for copying.
Change-Id: I877a4d8e169919d26878cb9c98782c637479d77a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105490
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ieeef0309faa77558fb30fceaed83ad97fb6e26ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105590
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If2984a0de77dcd4848f612f057b3e0a79ffef21a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105582
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: If268d7731642a6503418ca187b4fe85a889d1d2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105581
Reviewed-by: Lionel Mamane <lionel@mamane.lu>
Tested-by: Jenkins
|
|
* Update dictionaries from branch 'master'
to d6160c5e006089c711f3fec6eb4e2ade60a4150c
- Fix paths for pt_PT dict
Change-Id: I388ec82040aec9ad6a6454e9cc770ba0dc1be011
Reviewed-on: https://gerrit.libreoffice.org/c/dictionaries/+/105597
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie75e42e278a32d3a4130ec65a1ed05265fbc6f91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105599
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ibd3fe335e645895eedb6330cfc98590ad3c31fb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105578
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
* Update translations from branch 'master'
to c5f9a42b10e393fe6b295117427e088ff3279187
- Typos for an_ES.po
Change-Id: Idd4358fd6843cb34ec95ef726567416aeabe9598
|
|
Change-Id: I41ad8001e78ea82bf4d893b5faaa28400ff6efcf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105575
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
4deadc3c78949c18bb886eb1f66caa8f3cd7a2df made OutputDevice::DrawLine()
use SalGraphics::DrawPolyLine() in more cases, which revealed that
the the function was bailing out after the call and not drawing
also to mpAlphaVDev.
Change-Id: I1145d3684835b536737311294edfc566d5eb9025
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105553
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Ib3f2bf32bf65753ae935e30bbc2749df08334e0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105455
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
|
|
found by grepping and changed by hand.
Change-Id: I3c720859dba430fde3abc76c6c5cb58269efaf4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105512
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I942d478cd870036710390d2c03413b6fc0454038
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103619
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104808
Tested-by: Jenkins
|
|
* Update helpcontent2 from branch 'master'
to 8539d61c5ecca6748e4734671a86783de5fdd4b2
- Resolves: tdf#130719 add "note" about loading and overwriting styles
- drop existing "warning" under overwrite (because
it simply repeats what the function is doing).
+ added sentence to overwrite explanation to mention
that no warning message is given when overwriting.
+ Replaced "warning" with "note" that explains what
styles actually get loaded.
+ update to <h2>
Change-Id: I7a2af3627fbf53974f0e6b131660c6227a22e1f6
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/105361
Reviewed-by: Seth Chaiklin <sdc.blanco@youmail.dk>
Tested-by: Jenkins
|
|
Change-Id: I9a7945f6bc1ed176dc4662571ebd876b61662e2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105568
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
clean-up of commit cf596c43315bb96b5e7256a82256f1ccb8c9c4d0
(tdf#133163 DOCX: export formula cell).
The problem was reported by Miklós Vajna.
Change-Id: Ia636a6ffe8386e58e31e37c0d8afc283e6f2fc4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105558
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
And also introduce an enum class for the return type.
Change-Id: I6577c7678889ac5bb8efbf0d0cfeb575aac06e27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105567
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I1e27a17575963d084eb761f5a715f451db4bac62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105522
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: Ice850a7929c5b88ca0c4da52504aa959aacd1024
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105548
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Bjoern Kirchhoff <Bjoern.Kirchhoff@escriba.de>
|
|
Color.hxx has now documentation ( even if it is quite obvious if you know RGB standar ).
Color.hxx has been reordered in more coherent order, but kept format.
Some changes on Color.hxx dynamics.
Color.hxx starmath colors list
Now colors are managed by starmathdatabse.
The path is open for simple addition of colors, there are no more infinite switches with color tokens here and there.
To add a color, just put it in Color.hxx and register it in starmathdatabse.cxx. Do not forget to change array size in starmathdatabase.hxx.
Now mathml supports RGB colors in #RRGGBB format ( import and export ).
New colors have been added. Only the HTML Css1 are available via UI.
New colors will be added. I intend to finish Css2 and dvipsnames ( latex colors ) on posterior patches.
RGBA command has been unlocked for compatibility reasons. However will be displayed as RGB.
Added color #RRGGBB.
Improved qa color test on mathml to test RGB on mathml.
TODO for someone on the UI team:
- Add a color picker.
- If it is a color with name:
- It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" "
- If not:
- It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" "+ colorvalue.getRed() +" "+ colorvalue.getGreen() +" "+ colorvalue.getBlue() +" "
- Note that those will habe eType with value TRGB or TRGBA.
Change-Id: I47af37bd191b3099e8e6e08e7a5fb1a8a227bbf2
Change-Id: If971473ddcc34739439818dba9a62ca3494a4473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|