summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2020-09-18Resolves tdf#97918 - Individual UNO commands for distribution optionsHeiko Tietze3-14/+10
New UNO commands added, SID_DISTRIBUTE_DLG bend to dropdown, ui removed Menus and toolbars adjusted Change-Id: Ic0a3cc299f745a1a0cd18edead1f410ff57a1f1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102272 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-17fix LTO+mergedlibs on windowsNoel Grandin1-1/+2
Change-Id: I3d95d566db76e14532945b881b1847ea8c7e3153 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102946 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-17osl+tools: fix Windows Arm64 buildJan-Marek Glogowski1-1/+1
Change-Id: I17cbc1c8474880024921f476aa602d61978da868 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102851 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann6-105/+212
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16[API CHANGE] Remove unused and deprecated sal_Char/sal_sChar/sal_uCharJulien Nabet1-18/+0
These are deprecated since 2013, see: deprecated since 2013, see: author Stephan Bergmann <[hidden email]> 2013-11-27 12:50:35 +0100 committer Stephan Bergmann <[hidden email]> 2013-11-27 12:52:32 +0100 commit d8565bd266939b4ae4231f5b2c7d6260bee404e9 (patch) tree c4dc8575d838bf7f588ebb5102acc62cf7651336 parent b5fced896632a3c07586702b461545667b33966e (diff) Mark sal_Char, sal_sChar, sal_uChar as deprecated ...there never was a good reason to have SAL abstractions for the C/C++ char types anyway. and last uses of sal_Char and sal_uChar have been replaced with: - https://cgit.freedesktop.org/libreoffice/core/commit/?id=04203a26757d26814a18c3251d1a97f6ded64a62 author Julien Nabet <serval2412@yahoo.fr> 2020-09-11 22:05:12 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2020-09-12 13:36:42 +0200 commit 04203a26757d26814a18c3251d1a97f6ded64a62 (patch) tree 80962f43d3b46e8670ad49068a1a6e8459c22f39 parent 05d5062dca095f2e53de26db41edeb0b1279138b (diff) Replace remaining uses of sal_Char + remove sal_Char check on compilerplugins - https://cgit.freedesktop.org/libreoffice/core/commit/?id=70666469b87ab1e3589db0f5f7a236d744e83733 author Julien Nabet <serval2412@yahoo.fr> 2020-09-11 17:38:21 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2020-09-12 18:54:15 +0200 commit 70666469b87ab1e3589db0f5f7a236d744e83733 (patch) tree 88ee34da282712ea32e6354be92472f5fa52f1d4 parent 8214051829468c783404faf19194b26b35833e41 (diff) Replace remaining uses of sal_uCharHEADmaster The goal is then to remove sal_uChar completely since it's been deprecated in 2013! See http://document-foundation-mail-archive.969070.n3.nabble.com/About-removing-long-time-deprecated-types-from-public-API-tt4287268.html Change-Id: Ifc6057f49b6022a917d479c6f403b3f65454c510 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102436 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-15Fix typo in codeAndrea Gelmini1-1/+1
It passed "make check" on Linux Change-Id: Id56c9b50540a4de1950dfc4b49ea783d164a6604 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101811 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-15Replace FindCmap with ParseCMAPJan-Marek Glogowski1-0/+6
This introduces a potential performance regression, because FindCmap works on the existing font tables and just sets up a lookup function, while ParseCMAP creates some optimized, in-memory lookup table, which needs a bit more work, but is faster in its usage, I think. At least the initial usage is faster the old way, as the CMAPs aren't decoded at all. As you can see, the old code is just used on Windows and MacOS / iOS. Deep in the bowels of the PrintFontManager, the CMAP is also decoded using ParseCMAP... So I'm not sure this potential regression really exists. Most fonts will already have a decoded CMAP, so my guess is this is actually faster in the end. No idea, how to measure. Change-Id: I52caac1264cd3ff11a2a3fa6e9c800f67f146a79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102685 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-13Unify the code used to get object shell for componentsMike Kaganski1-2/+2
and their parents across the codebase. Change-Id: Ifb37fb940d285f81c1724a912204533e8c3b0044 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102546 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-09-13std::set->o3tl::sorted_vector in svxNoel Grandin3-7/+21
Change-Id: I86154a8ddf885ea23ff29e4df1b67e7501b9165b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102536 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-12replace sal_IntPtr with simple integer typeCaolán McNamara1-6/+5
Change-Id: I5aaf606b684b69641a872b3405b4d4d378289ad4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102466 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-12Replace remaining uses of sal_CharJulien Nabet22-187/+187
+ remove sal_Char check on compilerplugins Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9 Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11oox smartart: add support for syncing font heights of multiple shapesMiklos Vajna2-0/+20
When 2 or more shapes have their text set to autofit and they have a constraint like: <dgm:constr type="primFontSz" for="des" forName="node" op="equ"/> Then make sure that the automatic font size is the same for all shapes and all content fits, by using the smallest scaling factor from all relevant shapes. Some rework is needed, because normally oox::drawingml::Shapes don't have access to their parents, at the same time there can be multiple SmartArts on a single slide, so storing the grouping info in the filter is problematic, too. Solve this by storing the grouping in the toplevel oox::drawingml::Shape and exposing them in XmlFilterBase just during the time the children of the toplevel shape of the SmartArt are added. This works, because we know SmartArts can't be nested. Change-Id: I6c591eadc7166c7c42752650afdb7ee1e416cff6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102490 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-11tdf#135667 DOCX export: fix border line of OLE objectsAttila Bakos1-0/+1
which wasn't exported. Note: the enlarged monolithic export function was split in the following new functions: - WriteOLEShape() exports the replacement shape of the OLE object. - GetOLEStyle() returns the string value of the style attribute. - ExportOLESurround() handles the surround settings. Also add GetVMLShapeTypeDefinition() to reuse picture frame VML formula string used by VMLExport. Co-authored-by: Arató Dániel (NISZ) Change-Id: I29800a50c60a824a14849ac286a18e5e2f97c689 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102034 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-11invalidate prerendered fontname cache on style changeCaolán McNamara1-2/+4
Change-Id: Ie2111f23dc3346b914442090e3d9257c5659fafc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102459 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-11remove duplicate XML_TOK_TEXT_FRAME_FILTER_NAMENoel Grandin1-1/+0
which has been there ever since commit fd069bee7e57ad529c3c0974559fd2d84ec3151a Date: Mon Sep 18 16:07:07 2000 +0000 initial import And add assert to prevent more duplicates Change-Id: I371a117896c1ab36fabf69da41229a7bcf5459d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102366 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11convert IMAP_OBJ to scoped enumNoel Grandin4-8/+11
Change-Id: Id265c098a173b2daf581568779d99c7574f067c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102406 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11convert IMAP_FORMAT to scoped enumNoel Grandin2-7/+10
Change-Id: I58090ced672267614ade2e3e81e6264d01b77901 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102405 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-10support attempting to set a foreground color for labels and textviewsCaolán McNamara1-1/+12
but try to discourage use of random colors Change-Id: I1a67956846b8bd056180b37547ca7d206970c0e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102014 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-10tdf#136238 speed up deleting large cross page tableNoel Grandin1-1/+1
Goes from more than 30s to less than 1s on my pc. We were getting stuck inside the loop in sw::UndoManager::AddUndoAction, because the RemoveOldestUndoAction was continually doing nothing because it was hitting the if ( IsInListAction() { assert(!"SfxUndoManager::RemoveOldestUndoActions: cannot remove a not-yet-closed list action!"); return; } code. Which means that there is some bug here, but I'm not sure what. We are deep inside the delete logic at that point, and it doesn't seem unreasonable to opportunistically delete some of the UNDO list at that point. So the real fix is just the conversion from a while loop to an if-check. Change-Id: Ie2707009dd6574b996421f67d952ab9fdaaaf6aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102378 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-10tdf#131581 inhibit updates during all_foreachCaolán McNamara1-0/+1
Change-Id: I8494b4c9175e427bfb89696d49c2da7607af37ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102371 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-10cid#1466656 silence Logically dead codeCaolán McNamara1-0/+18
Change-Id: Id49181f71390ff6768ce6bc5734f8166e1a310b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102293 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-09svx UNO API for shapes: allow setting a max factor for autofit text scaleMiklos Vajna3-2/+12
This allows getting the scale factor from multiple shapes (that have text), seeing what factors they use and then setting the factor to the minimum of the values. Towards allowing both "autofit" and "same font size for these shapes" at the same time for SmartArt purposes. Change-Id: I31a5e097c62e6e65b32956a4a32137bc3339c64c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102324 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-09tdf#134413 must add scrollbar width on turning it off to occupy the same spaceCaolán McNamara1-0/+2
when scrollbars have width Change-Id: I3f9f6951add23f8ac93a03cf3356add5a2b3ddd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102275 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-09improve loplugin:unusedvarsglobalNoel Grandin2-3/+0
to find any global variable, was checking the wrong property of VarDecl Change-Id: I454b4e0c1701bb0771768a1ee10cd738c4ab0726 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102278 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-08svx UNO API for shapes: expose what scaling factor is used for autofit scalingMiklos Vajna2-2/+4
TextFitToSizeScale is 0 when the shape has no text or autofit is not enabled, 100 when there is autofit (but no scale-down), a value between the two otherwise. Towards allowing both "autofit" and "same font size for these shapes" at the same time for SmartArt purposes. Change-Id: Iff88fcc4c2e67b543687b1d87d614622cbf2e38a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102266 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-08tdf#134477 add VclMessageType::Other to indicate image-less generic InfoBoxCaolán McNamara1-1/+2
Change-Id: I76e86bf4d82b33771ea2900517712be57ae7f03d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102232 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-08cid#1466647 Resource leakCaolán McNamara1-0/+1
and cid#1466652 Resource leak cid#1466655 Resource leak cid#1466662 Resource leak Change-Id: I0f1bc254519dd79442493890dfdff3c1f9ce87d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102229 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann1-6/+43
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-07loplugin:constantparamNoel Grandin1-1/+1
Change-Id: I83722d99fa0d5919a7e878d32311dbb6de1c6714 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102175 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07Avoid dangling pData when constructing OUString from temporary OUStringLiteralStephan Bergmann1-0/+1
...afer 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String" Change-Id: I8afab29e9b7477c8a6c519b61d1fd6b3c21589e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102174 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-07copy docs to InvalidateFlagsNoel Grandin1-0/+7
from InvalidateStyle.idl, so I don't have to keep jumping around to figure out what this means Change-Id: Iee7d5f2a83afba075f15c44a36a5b4a8def04724 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102160 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07UNOTOOLS : simplify AccessibleStateSetHelper by not using an impl classArnaud Versini1-3/+1
Change-Id: Iae7a028d2845d8b0bef2aefdce2ae00fa7f5660f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102110 Tested-by: Jenkins Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
2020-09-06svx: Introduce createGalleryTheme() to GalleryThemeEntryAditya3-4/+12
Let GalleryThemeEntry initialize GalleryTheme. Change-Id: Ib81d95faf6561604a30a7d0a3d9dae808c83a398 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101655 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-06store annotation subtype in PDFGraphicAnnotation, enum for subtypeTomaž Vajngerl3-3/+57
Change-Id: Ib804f497a6c8f609e4899f9ebcef4c1096f44ce0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102090 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-06svx: Remove GalleryThemeEntry::createGalleryStorageEngineEntry()Aditya1-1/+0
Change-Id: I8e96e5e21c635bcd1e76f2fb6903116cff500892 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101643 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-06svx: Remove GalleryBinaryEngineEntry::createGalleryStorageLocations()Aditya1-1/+1
Initialize the member GalleryStorageLocations in the constructor only Change-Id: I0a37a1c87323d724f88b1de0aeb6151707b41853 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101642 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-06svx refactoring: Remove GalleryStorageLocations from GalleryThemeEntryAditya2-10/+18
Change-Id: I3955a66b7ec4f463264dbb5db6209bbb667bf2b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101557 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-06Fix warn "unbalanced grouping commands" in socket.hJulien Nabet1-0/+3
Change-Id: I290d96f8c2bcc9688e1d7acba95564b6bc97b64b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102097 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-05Fix typo in codeAndrea Gelmini1-1/+1
Change-Id: I2934b96c8b2b0a9049d7f238b9c67c8ecf56fa38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102035 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-09-05Make OUString(char16_t const[N]) ctor check for embedded NULsStephan Bergmann2-2/+11
...and fix the detected fallout. That ctor only started to get used recently with a1570b6052ae9c9349282027c9007b071589bce6 "Make the OUString ConstCharArrayDetector::TypeUtf16 overloads are actually used", but it turns out that that also gave rise to that ctor being picked in error. To better guard against such erroneous uses, make that ctor assert that the given array does not contain embedded NUL characters, see the new sal/qa/rtl/strings/nonconstarray.cxx tests. The one place where that assert would fire during `make check` is fixed now in SwWW8ImplReader::ImportDopTypography. That assert would also fire for tow OUStringLiteral-related tests in the recently added test::oustring::StringLiterals::checkEmbeddedNul, so drop those for how. They cna presumably be added back (with reversed logic values) when OUStringLiteral is changed similarly to how OStringLiteral was changed in 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Change-Id: I6056244003a20f77ba0d953538d25edcbd562211 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-04TabPage no longer needs to inherit from VclBuilderContainerCaolán McNamara1-4/+0
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-04svx refactoring: Remove GalleryThemeEntry::GetThmURL() and othersAditya3-7/+3
Remove GalleryThemeEntry::GetThmURL(), GetSdvURL(), GetSdgURL(), GetStrURL because they don't belong here because they deal with URL. Change-Id: I5a36742c49793726505ebbf394d9410194c39e6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101547 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-04svx: Introduce GalleryBinaryStorageLocationsAditya5-33/+70
Make GalleryStorageLocations abstract superclass of GalleryBinaryStorageLocations and upcoming GalleryXMLStorageLocations. Change-Id: Iccd53b723a4495e0d93ab5e3306f899ec41705f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101434 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-04svx: Refactor Gallery::ImplGetCachedThemeAditya3-4/+8
Introduce GalleryBinaryEngineEntry::getCachedTheme() to refactor Gallery::ImplGetCachedTheme. Change-Id: Ic27a325af0975298143d4746de363edd1d148a42 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101508 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-04xmlsecurity: pdf incremental updates that are non-commenting are invalidMiklos Vajna1-0/+4
I.e. it's OK to add incremental updates for annotation/commenting purposes and that doesn't invalite existing signatures. Everything else does. Change-Id: I4607c242b3c6f6b01517b02407e9e7a095e2e069 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102057 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-04svx: Introduce GalleryBinaryEngine::getModificationDate()Aditya1-4/+10
Also make GalleryBinaryEngine's functions GetSdgURL(), GetThmURL(), GetStrURL(), GetSdvURL() private to the class. Introduce getModificationDate() to GalleryBinaryEngine because that it where it belongs - it deals with URL Change-Id: Idd3c42e779652df030ae104e40581d9de1a07863 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101505 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-04svx: Refactor Gallery::RemoveTheme()Aditya5-8/+10
Introduce GalleryTheme::removeTheme() and GalleryBinaryEngine::removeTheme() Change-Id: Ic9c1b4fdb3e173d922635e5fd78d463e1f2c220a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101496 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-04svx: Refactor GalleryBrowser1::ImplFillExchangeDataAditya1-0/+4
Introduce GalleryTheme::getModificationDate() Change-Id: I1ca34482ee5f0007a1d698e345e399ac3de31a51 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101495 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-04svx: Rename GalleryThemeEntry::mpGalleryBinaryEngineEntryAditya1-7/+7
Rename mpGalleryBinaryEngineEntry to mpGalleryStorageEngineEntry because GalleryThemeEntry will have 2 engines: GalleryBinaryEngineEntry and GalleryXMLEngineEntry. Change-Id: I348d8df111f33cceacdbfe746bc484802fc18d13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101431 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-04svx: Rename GalleryTheme::mpGalleryBinaryEngineAditya1-3/+3
Rename mpGalleryBinaryEngine to mpGalleryStorageEngine because GalleryTheme will have 2 engines: GalleryBinaryEngine and GalleryXMLEngine. Change-Id: I990a3655121b4e4e5735c6a8d5e5afe13c674b20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101427 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-25 08:47:08 +0000