summaryrefslogtreecommitdiff
path: root/vcl
AgeCommit message (Collapse)Author
2020-09-22do not use SkShader if not neededLuboš Luňák
Change-Id: I9913673c889e605d608e25dad9a36b05912447be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103153 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-22fix parsing of Vulkan version numbersLuboš Luňák
The Windows+OpenGL handling pads the numbers so that .98 > 0.978, but Vulkan uses "normal" numeric ordering for versions. Change-Id: I766baf50e3505a96aa85163962400bb69c0acea6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103118 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21update pchesCaolán McNamara
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21weld infobarsCaolán McNamara
note: "pushed" status listener case dropped. Doesn't seem to be an expectation for it to something in infobars, and there doesn't seem to be a working case anyway. Change-Id: I7869cc05de9918f0dd70e28b0087205db6c9506c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101945 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21set properly font X-scale for Skia+X11 (tdf#136891)Luboš Luňák
Change-Id: I715453f6729363e6bf803f8493d91bb260fb808a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103097 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-21do not try to merge polygons if they do not share a point (tdf#136222)Luboš Luňák
If two polygons do not share a point, then they do not share an edge, so they cannot be adjacent polygons. As a side-effect this avoids the problem with tdf#136222, as it turns out basegfx::utils::mergeToSinglePolyPolygon() is broken with polygons that are almost but not quite adjacent. Change-Id: Ibf290cc886d7c337fd04c925b551b2e7773a6b70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102985 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2020-09-21add some more thaw/freeze usesCaolán McNamara
to try and squeeze out a little more performance. Its plausible that disconnecting the model from treeview with gtk_tree_view_set_model(..., nullptr) no longer improves times. If we didn't do that, then we could thaw/freeze without losing what nodes are expanded and the current scroll pos. Change-Id: I3f7da6e4873b37d53441abdb7e9e0b946b956ad4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103077 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21Missing includeStephan Bergmann
(for std::max, since f8474367449a1b6b54918d2753e3a36798761839 "ofz#25774 keep ParseCMAP within legal area") Change-Id: I873c788577e9ec3bd54d9e637d2cf86be7c1f6e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103089 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-20tdf#136559 We can get a performance boost from using a ListStoreCaolán McNamara
instead of a TreeStore if we only need a list see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2693 Change-Id: I03d03f2364ccc75b87d3f7c31d21ac9993fb384b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103036 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-20cid#1466875 Dereference null return valueCaolán McNamara
Change-Id: I6208d2d6e6592db89223c8a8705f7f1ba066f16e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103068 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-19fix non-pdfium buildNoel Grandin
Change-Id: Ic1e30a412927748ba58a21cf2ee922cd1a490aa4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103040 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-19Fix crash from broken font CMAP subtableJan-Marek Glogowski
ParseCMAP crashes on a broken CMAP subtable of a font used by the bugdoc of tdf#119074, which returns a negative offset (technically it's large positive offset turning into a wrong negative integer, which is still out of bounds of the CMAP overall size - you get the point). This simply ignores that broken subtable, checking for other existing ones. Regressed-by: c7482bc2904401e7d975b5721ec861b8589253f9 Change-Id: I95820fe3bb6bd2fe2e0cf9d4c3536abce31fd497 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103033 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18ofz#25774 keep ParseCMAP within legal areaCaolán McNamara
Change-Id: Ic68fadd3d63631cbccda76e7679d95bb89452d25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103017 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18[API CHANGE] tdf#136836 emfio: set size hint on inner PDF if used as shape fillMiklos Vajna
The bugdoc has a shape, its bitmap fill is an EMF, which is actually a PDF. The PDF is has a height of 5cm, but the shape has a height of 14 cm. Inform vcl::RenderPDFBitmaps() about the size of the shape, so the result won't be blurry. This approach makes sure that we don't unconditionally render at higher resolution, i.e. the "load a PDF of 100 pages into Online" use-case won't use more memory than before. API CHANGE, because the EMF reader is only available via UNO, though it's likely that no actual external code would ever invoke it directly. Change-Id: If1d8def0136d408a31a0cc54777a7f26430a0ff3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102996 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-18Fix typosAndrea Gelmini
Change-Id: I382bac84126095950a1d3932665c36fb16f1383b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101100 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18Related: tdf#136559 set multiple columns in model at the same timeCaolán McNamara
reduces time from 40s to 13s Change-Id: I01d6a4fcaa5a868f9b9f9292f4a7e99e216ea23b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102988 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18jsdialog: use window only if visibleSzymon Kłos
When there is a name conflict we should take currently visible window. Change-Id: Iaccf03a78b083ecaca0ee6aa538674a6de093a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102903 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102983 Tested-by: Jenkins
2020-09-17tdf#133690 Hide surrounding border frame at sidebarandreas kainz
Change-Id: I6daff0ae587232b4b31d02aeb2529eff3fba36a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102967 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-09-17Revert "remove border line from sidebar"Andreas Kainz
This reverts commit 1349e66ef629bfc8aed23434108339bdba5013bb. Reason for revert: <INSERT REASONING HERE> Change-Id: I2430718556745aa60e56f4c25b9dc8cb86644b2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102925 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-09-17qt5: Pass QStyleOption by reference instead of pointerMichael Weghorn
Change-Id: I12c88016740d94d4f2fcf0e1f83658dd2c3922a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102912 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-09-17tdf#136094 qt5: Handle bg color in drawNativeControlMichael Weghorn
This adds handling for the background color when drawing controls in the qt5 VCL plugin, as was done in the following commit for the gtk3 VCL plugin: commit 2c9052802ea411dffbf5906c4914611fcbfbc6a5 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Mon Aug 24 17:18:03 2020 +0200 tdf#136094 Handle background color in drawNativeControl For some reason, the proper background color is not passed to 'Qt5Graphics_Controls::drawNativeControl' for the multiline edit in the sample document ('rBackgroundColor is 'COL_AUTO' instead), while it works as expected for the gtk3 case. Setting a color inside 'Qt5Graphics_Controls::drawNativeControl' for testing purposes made that one show up, so the problem is elsewhere. I'll create a separate bug report to keep track of this and reference it in tdf#136094. Change-Id: I4df0d803c017422e0a2f5c05c6b4d2d8a8fa68c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102911 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-09-17Add schema comment to XML namespaced blockJan-Marek Glogowski
Just for reference, like all other namespaces. Change-Id: I1931063039e90c37ba54debb89d4e8994054f745
2020-09-17tdf#136805 PDF export: re-add XMP basic meta dataJan-Marek Glogowski
VeraPDF complains about: <rule specification="ISO 19005-1:2005" clause="6.7.3" testNumber="1" status="failed" passedChecks="0" failedChecks="1"> <description>If a document information dictionary does appear at a document, then all of its entries that have analogous properties in predefined XMP schemas, shall also be embedded in the file in XMP form with equivalent values.</description> <object>CosDocument</object> <test>doesInfoMatchXMP</test> <check status="failed"> <context>root</context> </check> </rule> The regressing commit dropped the XMP Basic schema meta data (http://ns.adobe.com/xap/1.0/"). FWIW: xmp is the referred prefix, so we'll continue to use it. Regressed-by: d016e052ddf30649ad9b729b59134ce1e90a0263 Change-Id: I11b06fdafcb07732b92f0bd99b18afa3a9e498ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102888 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...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-16jsdialog: export tooltip for drawing areasSzymon Kłos
Change-Id: I22a4eb9a74a81bbd2a26d5bae6b875a78a63acf9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102163 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102862 Tested-by: Jenkins
2020-09-16remove border line from sidebarandreas kainz
Change-Id: I520b6a5eaec5db065dc122b3e97861548347791e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102825 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-09-16ofz#25696 OOMCaolán McNamara
Change-Id: Ia69e9ce1ca0156e960dddb7e0bf98dfd2be2d7cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102846 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-15ofz#25684 keep ParseCMAP within legal areaCaolán McNamara
Change-Id: Iee18b5a9390b79efa67414ea2d229d2816c84e18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102776 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-15Fix typoAndrea Gelmini
Change-Id: I0ee96ee32e419138811f19226e87d21107877d85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102717 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-15WIN OSX Qt5 unify CreateFontSubset codeJan-Marek Glogowski
This is basically just some refactoring. Most interestingly the MacOS used to work with 257 glyphs. I couldn't find any explaination for the 256 glyph limit. Sadly the PrintFontManager is out of scope. That needs more inspection. Change-Id: Ibfa0e905f5efeb7d4a609884d64b4ed2615a9d3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102688 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins
2020-09-15Qt5 implement GetGlyphWidthsJan-Marek Glogowski
Basically implement it the same way then Windows and MacOS. Change-Id: I643581af49aeb9274505e90e12acbe5bcf0c98fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102687 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-15Forward existing FontCharMap from PhysicalFontFaceJan-Marek Glogowski
Since removed code in the previous commit is primary used in CreateFontSubset and GetGlyphWidths, you have a high chance, that the CMAP was already used for displaying a font, so it's already decoded and can be forwarded. Also the lookup should be faster in general this way. Change-Id: Icf4d8a1a84ff6ccdaccb7e870abe5df3837f9541 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102686 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins
2020-09-15Replace FindCmap with ParseCMAPJan-Marek Glogowski
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-15WIN OSX unify GetGlyphWidths codeJan-Marek Glogowski
Now that GetFontChatMap is a member of PhysicalFontFace, we can copy the common part of both architectures into a SalGraphics helper function. Change-Id: Iad379ea690a1c5346b69b5042188506ccf575cc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102684 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-15VCL register common functions in PhysicalFontFaceJan-Marek Glogowski
This makes GetFontCapabilities and GetFontChatMap members of the PhysicalFontFace. These are implemented in all the real font face classes anyway. Also provide dummies for the PDF buildin fonts. Change-Id: Icb8cb14480ce1e020977b8f69892095d787982ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102683 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins
2020-09-13tdf#125234 Qt5 add missing CFF font subsettingJan-Marek Glogowski
Implemented like on Windows and MacOS. Change-Id: Ib0d5125b77770446d4ca01efbb7c54d9c6bdb2e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102594 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-13tdf#132561 fix png export from DrawNoel Grandin
fixes a regression from commit 61e8387fa8ab55a04b95839c7c385c163d6de1cd tdf#128992 Compressing PNG files with alpha channel get a black background Change-Id: I8a225f76072c49f64393bb4b28c4d92c6e85587e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102548 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-12Replace remaining uses of sal_uCharJulien Nabet
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: I1ed6a56075a47fbfeac97388432bffcbd2ef1f7b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102491 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-12Fix typoAndrea Gelmini
Change-Id: I6ec0c6a97ec663223f6bca9ee5e9d8d27cdbf9f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102516 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-11tdf#125234 Qt5 set glpyh font bounding boxJan-Marek Glogowski
Not sure if this is strictly needed, and obviously it will be "wrong" for a sub font containing just some of the glyphs, but since other backends also do this, follow suit. Change-Id: Ib83542b685b38d800d09b7a19780f9ac619c7ad0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102487 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11Qt5 add some output formaters for Qt classesJan-Marek Glogowski
This simply converts them to LO equivalents. Since this is just for easier debugging, there is IMHO no need for "more optimized" variants. Change-Id: I283d0e2b69f945517aaa79f3c6dbea38dcb50ef0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102489 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11tdf#125234 Qt use glyph widths, not advanceJan-Marek Glogowski
We're working on the font level here, not the layouting. So use LO's TTF functions to read the glyph widths of the font directly. Change-Id: Ib3bd59a91aa08ca9e629a45ba7539d757bef2c1a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102488 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11Fix the minimal build-tools targetJan-Marek Glogowski
The revert commits change the build-tools target for a DESKTOP build to build the complete LO. This restores the original, minimal one and also adds a whitelist of allowd build types. OpenCL needs a configure switch, as it's status is also stored in a config header, so preventing the build is not enough. This also reverts: - commit 802161a505272732566210e9ebbd8fe1b23fb86d - commit 02d931a59e2966d0c2736db8dee7be3e3dcd6bae Change-Id: Ibfcb0c54e72da1b7c2e63c082ea6586520a787fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102480 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11tdf#135565 prepare font preview virtual deviceCaolán McNamara
make SalInstanceComboBox::create_render_virtual_device do more setup to have an appropiate default background. Change-Id: I43aeb6ffe85d21f11f3ebb1f981c0db67247e5db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102403 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins
2020-09-11drop misleading GetWindowTextColor useCaolán McNamara
We use a font from StyleSettings::GetFieldFont(), but use a font color from StyleSettings::GetWindowTextColor() and then immediately afterwards use SetTextColor(StyleSettings::GetFieldTextColor()); Change-Id: I60f653947242a4e2d5fe48bd1d0df7a3ab693685 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102461 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-11Do not even unload cui library during exitStephan Bergmann
<https://gerrit.libreoffice.org/c/core/+/102222> "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString" kept crashing in UITest_sw_options: VclAbstractDialogFactory::Create loaded the cui library, then some code created OUString instances pointing at the > const OUStringLiteral VIEWOPT_DATANAME = u"page data"; (cui/source/options/treeopt.cxx) in the cui library's rodata section, and at least one of those OUString instances ended up in the data structures owned by the static configmgr::Components singleton (configmgr/source/components.cxx). Now the UITest_sw_options test code in sw/qa/uitest/options/tdf78133.py makes some modifications that apparently cause SvtLinguConfig (unotools/source/config/lingucfg.cxx) to be used but, for whatever reason (i.e., whether or not that is another bug that would benefit from chasing it down), not get cleaned up properly, so that during termination, > warn:unotools.config:799178:799178:unotools/source/config/configmgr.cxx:140: ConfigManager not empty gets emitted, and that SvtLinguConfig apparently holds on to configmgr data so that the configmgr::Components singleton data structures are not fully cleaned up prior to exit. So when the exit handlers run, they happened to be run in such an order that first this static aDialogLibrary was destroyed, causing the cui library (and its rodata segment) to be unloaded, and only then the static configmgr::Components singleton was destroyed. The latter tried to remove all its not-yet-cleaned-up (see above) data structures, which still referenced an OUString instance containing a---meanwhile dangling---pointer to VIEWOPT_DATANAME, causing a crash. So instead of a static Module, use Module::release, as is already used in other places loading libraries. Change-Id: Ibc16d26f6125d20317a641b95ef71b4b406f0999 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102456 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-11application level settings-changed event callbacks not triggeringCaolán McNamara
this was originally... ImplDelData aDel( pWinEvent->GetWindow() ); while ( aIter != aEnd && !aDel.IsDead() ) before commit 1db7af8bc9febdf72138fac533ec81d6983da729 Date: Tue Jan 26 22:10:52 2016 +0530 tdf#96888 - Kill internal vcl dog-tags ... back then if GetWindow was null ImplDelData.IsDead() was always false Change-Id: I1e75c27635532afa08ed43bf92bda35b34ae6320 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102455 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-11convert IMAP_OBJ to scoped enumNoel Grandin
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 Grandin
Change-Id: I58090ced672267614ade2e3e81e6264d01b77901 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102405 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-02-07 08:31:21 +0000