summaryrefslogtreecommitdiff
path: root/fpicker/UIConfig_fps.mk
blob: c5582587bda59107ecec0089c2fcac56a129b85e (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
#
# This file is part of the LibreOffice project.
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
#

$(eval $(call gb_UIConfig_UIConfig,fps))

$(eval $(call gb_UIConfig_add_uifiles,fps,\
	fpicker/uiconfig/ui/explorerfiledialog \
	fpicker/uiconfig/ui/foldernamedialog \
))

# vim: set noet sw=4 ts=4:
generated by cgit (git 2.34.1) at 2025-02-23 01:49:52 +0000
which means we don't need to allocate a bunch of strings when building the property maps in xmloff Change-Id: I83cb013f816d9b7bcb0dd55c59e5151b33b91c9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142192 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-06-24clang-tidy modernize-pass-by-value in reportdesignNoel Grandin Change-Id: I2c005a2f66139237cb1ebf09812f31fb08f53c90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136397 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2021-10-26Replace macros from reportdesign/source/ui/inspection/metadata.cxxJulien Nabet Change-Id: I779b6a20b814815b480876d8e65ef6b8e80f9443 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124241 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-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-01-28tdf#96505: Get rid of cargo cult long integer literalsOnur Yilmaz I checked return values. Long variables didn't affect the calculation. Change-Id: Ia3713eedf275de71b1096d1fe7e22da012a7f94e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87493 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com> 2019-11-22Extend loplugin:external to warn about classesStephan Bergmann ...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-09-13tdf#45789 [API CHANGE] Automatic row height in reportsIlhan Yesil The controls have now an AutoGrow flag which is saved as style:min-row-height instead of style:row-height on style:table-row-properties in content.xml. In this case the table row height will be allowed to grow to accommodate the content. Note: in the conceptual model of reportdesigner this is a per-control property but in the current implementation, it is a per-row property in the ODF file. Thus, as soon as one control in the row has the AutoGrow property set, they all do. Change-Id: I95c25599e06af0f2f12e72a7cfc0881206f02039 Reviewed-on: https://gerrit.libreoffice.org/53977 Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu> Tested-by: Jenkins 2019-08-15loplugin:sequenceloop in postprocess..reportdesignNoel Grandin Change-Id: I86b9174c37e4a347a3a8ac6c2707052167e6fdc0 Reviewed-on: https://gerrit.libreoffice.org/77522 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2018-04-15remove some unused comphelper includesJochen Nitschke and fix the fallout Change-Id: I5d0c2040f57a3ac354a7e277592da31d09a5f359 Reviewed-on: https://gerrit.libreoffice.org/52894 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de> 2017-11-22Make loplugin:unnecessaryparen warn about (x) ? ... : ... after allStephan Bergmann ...which had been left out because "lots of our code uses this style, which I'm loathe to bulk-fix as yet", but now in <https://gerrit.libreoffice.org/#/c/45060/1/> "use std::unique_ptr" would have caused an otherwise innocent-looking code change to trigger a loplugin:unnecessaryparen warning for pFormat = (pGrfObj) ? ... (barring a change to ignoreAllImplicit in compilerplugins/clang/unnecessaryparen.cxx similar to that in <https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in loplugin:simplifybool consistent", which should also have caused the warning to disappear for the modified code, IIUC). Change-Id: I8bff0cc11bbb839ef06d07b8d9237f150804fec2 Reviewed-on: https://gerrit.libreoffice.org/45088 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2017-10-23loplugin:includeform: reportdesignStephan Bergmann Change-Id: Ie531677be09c264ed1536ad2512e76f29ab46881 2017-07-21de-hrc various thingsCaolán McNamara e.g. helpid[s].hrc -> helpids.h and insert include guards where missing move "ordinary" defines into .hxx files remove .hrc entries that are used as arguments to dialog factory when a dedicated method can be added instead Change-Id: I792fb8eb0adfaa63cf354e6e57401fc943e9196e 2017-07-21migrate to boost::gettextCaolán McNamara * all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string") * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching MODULE .mo files * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui goes from l10n target to normal one, so the res/lang.zips of UI files go away * translation via Translation::get(hrc-define-key, imbued-std::locale) * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there to keep finding the .hrc file uniform) so magic numbers can go away there * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation mechanism * en-US res files go away, their strings are now the .hrc keys in the source code * remaining .res files are replaced by .mo files * in .res/.ui-lang-zip files, the old scheme missing translations of strings results in inserting the english original so something can be found, now the standard fallback of using the english original from the source key is used, so partial translations shrink dramatically in size * extract .hrc strings with hrcex which backs onto xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap * extract .ui strings with uiex which backs onto xgettext --add-comments --no-wrap * qtz for gettext translations is generated at runtime as ascii-ified crc32 of content + "|" + msgid * [API CHANGE] remove deprecated binary .res resouce loader related uno apis com::sun::star::resource::OfficeResourceLoader com::sun::star::resource::XResourceBundleLoader com::sun::star::resource::XResourceBundle when translating strings via uno apis com.sun.star.resource.StringResourceWithLocation can continue to be used Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a 2017-07-11use more range-for on uno::SequenceNoel Grandin Change-Id: Ifad32425d79be5a22d33d721bdc5fb993f699759 Reviewed-on: https://gerrit.libreoffice.org/39763 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> 2017-07-07C++11 remove std::binary_function bases from functorsJochen Nitschke std::binary_function is deprecated since C++11 and removed in C++17 90% done with regexp magic. removed obsolete <functional> includes. The std::binary_function base class was used by deprecated std::bind2nd, this was solved in individual commits. The members first_argument_type and second_argument_type were used in chart2/source/controller/dialogs/DataBrowserModel.cxx: DataBrowserModel::implColumnLess and are inlined in this commit. Change-Id: I60ded60a8d4afd59e15ac15a58e18d2498c9be5a Reviewed-on: https://gerrit.libreoffice.org/39659 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2017-06-26Translate German comments and debug strings (leftovers in r... dirs)Johnny_M Translates all (leftovers) found using a custom regex, in directories not shown by /bin/find-german-comments and beginning with "r". Additionally: - Translates test strings in /registry/test/testregcpp.cxx Change-Id: I9fda72a3d1830268c4eb83d67ee7a95e38c31c0d Reviewed-on: https://gerrit.libreoffice.org/39210 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2017-03-19TyposJulien Nabet Change-Id: I13020539fe121151e884a90d72d47788fb3ae65c Reviewed-on: https://gerrit.libreoffice.org/35436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2016-12-17Adapt to no-longer explicit OUStringLiteral ctorStephan Bergmann ...from previous commit Change-Id: I062b7cd212c17e7eb5274476e6859228d0477c7f Reviewed-on: https://gerrit.libreoffice.org/32098 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com> 2016-10-13move this monstrosity to the last place its usedCaolán McNamara Change-Id: I4691f20143406249afc8da1a6dfa901224f4a62d 2016-08-16new loplugin to check for static OUStringsNoel Grandin that are better declared as OUStringLiteral Change-Id: Ifb5d9a12bb31a68641940bec16971a8181a46567 Reviewed-on: https://gerrit.libreoffice.org/27377 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com> 2016-05-20Convert PROP_FLAG to scoped enumNoel Grandin Change-Id: Ia08a22cffa07c6c3a82497671d0e246fc5aa88a0 Reviewed-on: https://gerrit.libreoffice.org/25163 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com> 2016-03-31use SAL_N_ELEMENTS in for loopsNoel Grandin for with git grep -n 'for.*sizeof' Change-Id: I6211024385e03ac5eeeb38690d2c1c699e015c2f Reviewed-on: https://gerrit.libreoffice.org/23569 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com> 2016-02-09Remove excess newlinesChris Sherlock A ridiculously fast way of doing this is: for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \ --exclude-dir=workdir --exclude-dir=instdir '^ {3,}' .) do perl -0777 -i -pe 's/^ {3,}/ /gm' $i done Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c Reviewed-on: https://gerrit.libreoffice.org/22224 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> 2015-11-10loplugin:nullptr (automatic rewrite)Stephan Bergmann Change-Id: I9cace0074f2fd0e71e41779b9edd099abfa8dedc 2015-10-26com::sun::star->css in remotebridges,reportdesignNoel Grandin Change-Id: Id210cbc3481a8a31e6fc0ba2028346fc585c8744 Reviewed-on: https://gerrit.libreoffice.org/19597 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>