summaryrefslogtreecommitdiff
path: root/toolkit
AgeCommit message (Collapse)Author
2021-02-23loplugin:refcounting in toolkitNoel
Change-Id: I4a65ee848eed7c48340c73d3144b4a1e29ab867c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111370 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-22forward declare some things and avoid includesCaolán McNamara
Change-Id: I8bf6e23904c932de646aa84fffab1b5549dbdf31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111349 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-22Adapt to changed CreateWindow signatureStephan Bergmann
...in 197bcde5c4d771ace11962213c11c9763be11039 "loplugin:refcounting in svtools", see UBSan > toolkit/source/awt/vclxtoolkit.cxx:1912:22: runtime error: call to function CreateWindow through pointer to incorrect function type 'vcl::Window *(*)(VCLXWindow **, const com::sun::star::awt::WindowDescriptor *, vcl::Window *, long)' > svtools/source/uno/unoiface.cxx:29: note: CreateWindow defined here > #0 in (anonymous namespace)::VCLXToolkit::ImplCreateWindow(com::sun::star::awt::WindowDescriptor const&, MessBoxStyle) at toolkit/source/awt/vclxtoolkit.cxx:1912:22 during CppunitTest_toolkit Change-Id: I1fdf977ed8f0ae67c09ba1e1565499db3f9f1af3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111305 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2021-02-19foward declare NotebookBarAddonsItem instead of using includeCaolán McNamara
Change-Id: I57e5a8f28a40994b61ab0f554401e4f70c8ffc12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111230 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-17loplugin:referencecasting in test..toolkitNoel
Change-Id: Ia290ff4849f4d7eda978c7b1e2c7f36de744056f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110997 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-08Improve loplugin:cppunitassertequal for CPPUNIT_ASSERT(a && b)Stephan Bergmann
...by re-enabling the code temporarily #if'ed-out in a528392e71bc70136021be4e3d83732fccbb885e "Fixed/improved loplugin:cppunitassertequals" (and which then triggers lots of other lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings). For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it was more straightforward to rewrite them with an explicit call to operator == (which silences loplugin:cppunitassertequal) than to adapt them to CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types. In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been implemented trivially for now, but might want to combine that with the DEBUG_PIVOT_TABLE-only ScDPItemData::Dump. Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-06move MenuButton to vcl/toolkitCaolán McNamara
Change-Id: I3f228c36e3f35ba54cab2ee87fcfbbae7992668d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107265 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-28simplify code, use more subView()Noel
Change-Id: I569c7f34acbdf8451cd5c9acf1abd334637072d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110051 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-27tdf#139609 avoid fetching unnecessary xid under gtk3Caolán McNamara
because of the side effects using a bare GtkGrid as m_pSocket in vcl/unx/gtk3/gtk3gtkobject.cxx is perhaps a poor choice, getting its xid causes poor side effects wrt events belonging to its child widgets getting delivered to the SalFrame widget, so duplicate scrolling after showing a opengl slide and/or showing a video and lots of flickering we're (generally at least) not using the xid under gtk3 so don't set it unless it's explicitly asked for. Happily the gtk Player::createPlayerWindow doesn't use its arg[0] xid in any case, so don't bother setting it for that backend. Change-Id: I1c59a607a332635091782c3b49de10647558f301 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109941 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-26use an accessor for SystemEnvData::aWindowCaolán McNamara
with an eye to making it on-demand Change-Id: If6cefd68a336dc6afe23591c857bd71034215b54 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109929 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-25avoid some ref-countingNoel Grandin
can just return a pointer here, instead of VclPtr. Change-Id: I9ab8962cbbe84ed4dfcfd658a6d758112914cb89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109923 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-24Use ContainerType().swap and avoid local variablesMike Kaganski
Change-Id: I773555180758a97aff37f9bc27de83c355d71521 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109761 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-16make the Color constructors explicitly specify transparencyNoel
to reduce the churn, we leave the existing constructor in place, and add a clang plugin to detect when the value passed to the existing constructor may contain transparency/alpha data. i.e. we leave expressions like Color(0xffffff) alone, but warn about any non-constant expression, and any expression like Color(0xff000000) Change-Id: Id2ce58e08882d9b7bd0b9f88eca97359dcdbcc8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109362 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-09fix coverity parse errorsCaolán McNamara
Change-Id: I3a1179947704452e3ffec02be59d0f7bf0b75ab0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109017 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-02tdf#74702 - vcl: introduce OutputDevice::GetDeviceInfo()Chris Sherlock
Change-Id: I02c9cc83fea330ed0ba1539b2682f75d33ba80fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108132 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-25tdf#88205: Adapt uses of css::uno::Sequence to use initializer_list ctorBayram Çiçek
Change-Id: Ib9384b5106ef389b027787432c32e387a5f9ad81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108268 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-04add a way to get an awt::XPopupMenu from a PopupMenuCaolán McNamara
Change-Id: Ia1cde3b60b71ed9e4d0b7dc8d9ad0b2899d60b98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107229 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-01OSL_FAIL.*exception -> TOOLS_WARN_EXCEPTIONNoel
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-18tdf#123936 Formatting files in module toolkit with clang-formatPhilipp Hofer
Change-Id: Ib4ee991a05335247d65343dfd3c3bcaf214a9e06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105720 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-11-14tdf#138187 Don't open UNO hyperlink control's URL twiceMichael Weghorn
It looks like handling the click by opening the URL was added directly to 'FixedHyperlink' in commit f0006e79c4112b06b65c098722729b9a3f3301c7 Date: Thu Oct 20 10:49:24 2016 +0200 Handle link click directly in FixedHyperlink to deduplicate the handling done explicitly in various dialogs by themselves. The handling in 'VCLXFixedHyperlink::ProcessWindowEvent', which did the same for the case where no action listeners exist, there since commit ea665e6fe7af34fcdcefd73bc05c68eb88e42073 Date: Tue Jan 29 14:05:57 2008 +0000 INTEGRATION: CWS fwk80_SRC680 (1.64.12); FILE MERGED 2008/01/24 12:27:38 pb 1.64.12.6: fix: #i83756# VCLXFixedHyperlink::ImplGetPropertyIds() added 2008/01/24 07:50:51 pb 1.64.12.5: RESYNC: (1.64-1.64.18.1); FILE MERGED 2008/01/15 09:14:01 mav 1.64.12.4: adopt for gcc 2008/01/15 08:13:04 pb 1.64.12.3: fix: #i83756# open the hyperlink if there are no action listeners 2008/01/14 09:48:30 pb 1.64.12.2: fix: #i83756# VCLXFixedHyperlink::get/setProperty() added 2008/01/11 15:04:28 pb 1.64.12.1: fix: #i83756# class VCLXFixedHyperlink remained, though, so clicking a UNO hyperlink control resulted in the corresponding URL being opened twice. Drop the extra handling from there so this only happens once. (I couldn't quickly double-check that the URL is only opened once before f0006e79c4112b06b65c098722729b9a3f3301c7 since opening the dialog from the sample file fails in such old versions in the bibisect repo.) Change-Id: I32eace51bf8f14e968a939398c2bf2fd6f83de28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105793 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-11-12Permit scrollable AWT tab pages a la scrolled DialogThorsten Behrens
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>
2020-11-11make tools::Long 64-bit on Windows platformNoel Grandin
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>
2020-10-28convert some more long -> tools::LongNoel
Change-Id: Ide9811c1a7582454b3fcf655b70ea106ed56509a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104914 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-28std::set->o3tl::sorted_vector in toolkitNoel Grandin
Change-Id: I1ef897d38c26d2875432d279fdd50d2e073ad2a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104903 Tested-by: Jenkins Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-26switching long to a 64-bit type on 64-bit windowsNoel
(*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-23Change SystemParentData::aWindow to sal_uIntPtrStephan Bergmann
...with similar reasoning as in 5d422c0348efd1df6b3d44dd6efcf5c5490fc321 "Revert 'sal_uIntPtr->unsigned long in SystemEnvData'": Prior to 3aef606f2758172a27718a06fea0ff9080e4d80f "use tools::Long in vcl" this was long, but besides X11 window resource IDs (for whose appropriate type see the commit message of 5d422c0348efd1df6b3d44dd6efcf5c5490fc321), at least vcl/unx/gtk3/gtk3gtkframe.cxx uses it in combination with GdkNativeWindow (e.g., GtkSalFrame::m_aForeignParentWindow and GtkSalFrame::findTopLevelSystemWindow), which itself is a typedef for sal_uIntPtr (vcl/inc/unx/gtk/gtkframe.hxx). Change-Id: I6d26ca7056da413d948215682425ee1ddb622326 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104695 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-10-21new tools::Degree10 strong typedefNoel Grandin
partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-20fix font orientation conversion in VCLUnoHelperNoel Grandin
css::awt::FontDescriptor uses degrees, while vcl::Font uses deci-degrees Change-Id: I72265ea6385bc61db99ee9a6bb392dab2cb1ab3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104543 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-11Revert "Permit scrollable AWT tab pages a la scrolled Dialog"Caolán McNamara
UITest_sort failing https://gerrit.libreoffice.org/c/core/+/103942 Jenkins Verified-1 Patch Set 7: Verified-1 where UITest_sort failed Jenkins Verified+1 Patch Set 7: Verified+1 but that's just an android build which doesn't run any tests This reverts commit b3f2530aa2767ba43cd4702422fc3ed0d37821d6. Change-Id: I9414e5d7cc5873848f95dab65f03836ccb2ff0c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104194 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-11Permit scrollable AWT tab pages a la scrolled DialogThorsten Behrens
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 Change-Id: Iff90f60d0152ca21e4fe61c31315b9e1feab0dea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103942 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-10-04loplugin:reducevarscope in toolkit..unotoolsNoel
Change-Id: I439b9f456ac0bfaa3eb9bf17472053bd4787e828 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103840 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-26Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I9114b844b014d561464317ad6f54b54fe5a81d72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103454 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-03Make ImpSvNumberformatScan::GetColor constMike Kaganski
Change-Id: Idbcce18029944ab884cdde03e21190cbb574a00f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102005 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2020-09-02move Edit into toolkit only headersCaolán McNamara
Change-Id: If51bf7143116721e8f16272cf8aff797651d5ed1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101880 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-01Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I5beec4b326b7f59103de374dff8169718defc8ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101779 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-20loplugin:virtualdeadNoel Grandin
Change-Id: Ib41d80d1e068d66edabdfb36061dd382dc34b04c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-08-19move VclMultiLineEdit to toolkit-only headersCaolán McNamara
Change-Id: I2e8728061e484f79768fcfe67d674cb76367a94d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100951 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-18move VCLXMultiLineEdit and MultiLineEdit to toolkitCaolán McNamara
Change-Id: I9aa4b1efbecb71141647dbf5d8809482be15d266 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100888 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-12SvTreeListBox can move into toolkit headers nowCaolán McNamara
Change-Id: I6b3b6ef1530a192f4b6bf87aa9688687063683ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100591 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-12svlbitm.hxx can be toolkit only nowCaolán McNamara
Change-Id: Ie5ad0febca0747fa66c2caede619d14e468da032 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100498 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-08-04loplugin:flatten in toolkitNoel Grandin
Change-Id: I8f4b29620134566f256f05bbab677e83baf20ec7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100031 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-25cid#1465510 Dereference null return valueCaolán McNamara
and cid#1465511 Dereference null return value Change-Id: Ie297ef070ecf712e989704b8c07907e2f6453cd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99428 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-23access via NumericFormatter instead of NumericFieldCaolán McNamara
Change-Id: I4f3c2e9f7249b77fbc509031f4eb5f170eac5b90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99318 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-23NumericFormatter can be toolkit only nowCaolán McNamara
Change-Id: Ied4d45b2eadb831cef1b277d67f520859f536644 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99312 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-21weld DateControlCaolán McNamara
replace SpinButton when WB_SPINBUTTON is set on a date field to always use a popover with a calendar in it to make it possible to integrate this with native widgets Change-Id: I36a26599a154bddf9aec9b50b6570e13477a1f63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98858 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2024-04-30 08:26:17 +0000