/source/es/librelogo/

Age	Commit message (Collapse)	Author
2024-05-17	loplugin:ostr in sc/../tool	Noel Grandin
	Change-Id: I04c41c79613397745a2e97c2e8a247e11f114c7c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167767 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2023-10-23	Extended loplugin:ostr: Rewrite some O[U]StringLiteral -> O[U]String	Stephan Bergmann
	...in include files. This is a mix of automatic rewriting in include files and manual fixups (mostly addressing loplugin:redundantfcast) in source files that include those. Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-20	Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: sc	Stephan Bergmann
	Change-Id: Ieed908bfa2cb6370ead922dfc00dbdb4f905f3cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158216 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-18	sc drawstyles: Maintain comment formatting with styles	Maxim Monastirsky
	Up to now the look of comments was maintained with the comment shape's DF, with the default formatting being reapplied on import (for hidden comments), on changing Tools > Options... > LibreOffice > AC > Notes background, and on changing the default cell style, while keeping the user-applied DF to some extent. However, as we attempt to support drawing styles, this approach is no longer viable, as applying DF on top of styles at random times makes styles useless in the context of comments. (One might argue, that the look of comments should ideally be treated as an app view setting, and not as a formatting of an individual shape. This definitely makes sense, but has compat. implications, as both LO and Excel allow formatting individual comments (e.g. show a comment, right click > Area...). However we will probably do it anyway if we ever implement threaded comments like in recent Excel [1], as the callout shape based approach seems to not scale to it.) One way around it could be to explicitly disable any style interaction with comments. But this will be unfortunate, as styles have a clear advantage of being able to consistently maintain the same formatting for several elements, much more that the fragile approach of mixing the default formatting and user-applied formatting in the same formatting layer. Not to mention the possibility to define several custom styles. In addition there is a request in tdf#55682 to disconnect the formatting of comments from the default cell style, having a dedicated style instead, which I find reasonable. So this commit introduces a comment style, and uses it for new comments instead of DF, making it easy to format all comments at once. And a style based formatting is never overriden with DF, unless explicitly set by the user. Changing Tools > Options... > LibreOffice > AC > Notes background still has an effect in two ways: (1) Sets the default background of the comment style for new documents, and (2) if changed while a document is open, changes also the comment style of the current document. An undo action is also added, in case changing the current document wasn't deliberate. Changing the default cell style no longer has any effect on comment formatting. One unfortunate side effect of this change, is that newly created and permanently visible comments will lose their default look when opened in an older version. But there is not much I can do here, as older versions don't support styles, and I believe the advantage of using styles outweigh this concern. Hidden comments are not affected by this. [1] see https://support.microsoft.com/en-us/office/the-difference-between-threaded-comments-and-notes-75a51eec-4092-42ab-abf8-7669077b7be3 Change-Id: I84215791b9e6ce393c6d979aa2b19ef70c76dff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150352 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2023-03-30	sc drawstyles: Add a default style and make use of it	Maxim Monastirsky
	The style is empty, similar to the default cell style, thus fall backs to the pool defaults for everything. This ensures compatibility with existing documents, despite the fact that the default style is applied to all shapes upon import. In addition, people who will ignore styles and just continue to use DF, will have their spreadsheets look the same in older versions that don't support styles. For this reason I also opted to not set a dedicated style for images and OLE objects via SdrModel::SetDefaultStyleSheetForSdrGrafObjAndSdrOle2Obj, unlike Impress/Draw, and continue setting the "no fill and no line" override as DF. Change-Id: I11554044a1aaf386dc6c4acdbab798fc5a231adc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149359 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2021-11-04	Move these SC_STYLE_PROG_* and SC_PIVOT_STYLE_PROG_* constexpr to header	Kevin Suo
	so that they can be reused in other parts of the code base. Need to change them to inline to avoid "defined but not used" compiling error. Change-Id: I44de7c2ebbc9ae57c229f89faf69a788013d7816 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124643 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-22	Extend loplugin:stringviewparam to starts/endsWith: sc	Stephan Bergmann
	Change-Id: Ibda7acf66bd8382de25fae9b4385d655be6ab409 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122490 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-02	convert #defines to OUStringLiteral	Noel Grandin
	mostly by doing $ git grep -l '#define.\"' -- .cxx \| xargs perl -pi -e 's/^#define\s+(\w+)\s+(\".*\")/constexpr OUStringLiteral \1 = u\2;/g' Change-Id: I7467f9067085ac89b98a0398811396c448339b4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119840 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-27	tdf#42949 Fix new IWYU warnings in directory sc/	Gabor Kelemen
	Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I217817e2e4a42b096f5a7fb6344568c10d69aab2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106078 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-06	tdf#134161: Revert "tdf#132137 Rename Default Style in Calc."	Xisco Fauli
	This reverts 4111ed76906bf6be05b704bf52fa91353dfef183 the document would also hang if define STR_STYLENAME_STANDARD NC_("STR_STYLENAME_STANDARD", "Default"); is replaced by define STR_STYLENAME_STANDARD NC_("STR_STYLENAME_STANDARD", "DefaultTest"); meaning somewhere in the code 'Default' is harcoded as git grep "\"Default\"" sc/source/ shows Reverting for now so we can backport it to libreoffice-7-0 while a better solution is provided for tdf#132137 Some other problems of the reverted commit are mentioned in comment 4 and comment 5 of tdf#134161 I'm adding a unittest in another commit so this one can be easily reverted in the future Change-Id: Ib7c4a99ff4957eba7ec0b644e989c7a08b46f2a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105381 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-10-10	Resolves: tdf#137370 Re-enable UI translated standard cell style names	Eike Rathke
	Regression from style rework commit 7b0aed617f1e57335837cf56ef2d222a96f8270d CommitDate: Wed Sep 28 11:42:56 2016 +0000 Remove old cell styles from calc to commit 06f319937187f76ee402d53b3baa78c391c2af19 CommitDate: Sun Oct 2 13:51:26 2016 +0000 tdf#90937 Add a set of cell styles to calc Change-Id: I34dddb3ca3e54e3da5db112e1f9bcc8437fbda77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104141 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-06-10	tdf#132137 Rename Default Style in Calc.	Srijan Bhatia
	Change-Id: I0f7c5ffc64b2387fbb63bb5724594480d3135f58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95484 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2019-11-22	Extend loplugin:external to warn about classes	Stephan 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>
2018-11-22	improve function-local statics in sc	Noel Grandin
	Change-Id: Ibde8aa9393591fe405bfad8ddb23ceda77723a35 Reviewed-on: https://gerrit.libreoffice.org/63781 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-05-12	Replace ScGlobal::GetRscString with simple ScResId calls	Gabor Kelemen
	After the gettext migration there is no point to have two APIs for reading the same .mo file. This patch is for sc/source/core/tool for easier review. Change-Id: I4722c8a9ce11ae073389ec8395401f3d11ef0d5b Reviewed-on: https://gerrit.libreoffice.org/54133 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-03-20	tdf#116470:Convert between ProgName/DisplayName for pivot table style	himajin100000
	to avoid styles in different languages to be unnecessarily registered Change-Id: I450909d798749f751b1c59cda28865f6c3ea76c3 Reviewed-on: https://gerrit.libreoffice.org/51511 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com>
2017-10-23	loplugin:includeform: sc	Stephan Bergmann
	Change-Id: I2ed763e0584a188032c80fde60890de3c6985cbd
2017-07-21	migrate to boost::gettext	Caolá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