summaryrefslogtreecommitdiff
path: root/svtools
AgeCommit message (Collapse)Author
2020-11-02remove duplicate initialisationNoel
Change-Id: Ia1b99ed420daf5d238082f374eab7b76920714f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105167 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02toolbox always has flat styleNoel Grandin
ever since commit c1cd6af623e86b5b1b45f9d09dc17d6fbb907f02 Author: Jens-Heiner Rechtien <hr@openoffice.org> Date: Mon May 10 14:51:02 2004 +0000 INTEGRATION: CWS nwf (1.64.66); FILE MERGED 2004/03/31 09:28:33 ssa 1.64.66.1: #i25130# force flat toolbox buttons except for a completely and utterly undocumented hack of a registry key, introduced in commit 736dc0956a50315ec72ad126406556657a750d37 Author: Rüdiger Timm <rt@openoffice.org> Date: Thu Apr 17 14:19:46 2003 +0000 INTEGRATION: CWS vcl08 (1.57.2.4.18); FILE MERGED 2003/04/14 17:46:27 ssa 1.57.2.4.18.1: #108699# disabled flat toolbox buttons not exported anymore which only seems to apply to Windows. So just remove this. Change-Id: Idf315b8c89c3119883a5e6880d003d379fe6faec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105155 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-02use officecfg or MacroRecorderModeNoel Grandin
Change-Id: I2a8d4f401ddfd4368a7b50b4c3c8a72724f9afa3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105154 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-01use officecfg for ShowLinkWarningDialogNoel Grandin
Change-Id: I92a42eb2ff48bff4e635f1a37a25c8ecb9ac1347 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105153 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-01use officecfg for IsPluginsEnabledNoel Grandin
Change-Id: Id80ba8a87af7f87b8232949b70804b1a021b23d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105147 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-01use officecfg for UseSystemFileDialogNoel Grandin
Change-Id: I1419af229a67d6ebb1cf2c63757656beb3f512db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105142 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-01use officecfg for UseSystemPrintDialogNoel Grandin
Change-Id: I0e0bdc925f106884cbcede6405cc6ef7152ad405 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105139 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-01use officecfg for Experimental flagNoel Grandin
move IsShowOutlineContentVisibilityButton out of header to avoid having to add extra include paths to all the unit test makefiles. Change-Id: I2763390e07cd85b8f09b6f2ad7702039daecb22f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105100 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-31remove pimpl in UnoControlTableModelNoel Grandin
Change-Id: Ia7aa2c5fa4d6bbe5cd722d8e27ec1a10c36fc4e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105028 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-30convert some tools::Long->sal_Int32Noel
in places where it is obvious we only need a sal_Int32, because we are dealing with rows and columns, and not even calc needs more than 32 bits for that. Change-Id: I114417e639c224d45bfd9fc6838122ab195eefa3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104584 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-29tdf#132536 free the cached VirtualDevicesJan-Marek Glogowski
Once again I forgot, that VclPtr is not really a shared pointer, as someone has to release the contained instance. It just prevents others from working on a dangling pointer and also freeing the contained instance multiple times. Using a "Scoped" variant in the vector instead of the loop doesn't compile. This fixes the major memory leak when deleting the last FontNameBox, which freed the caching VclPtr vector but not the contained VirtualDevice instances. It seems there is still some other minor leak left to fix, probably unrelated to the regressing patch. Found, after I realized the memory leak just happened with font preview enabled... Regressed-by: 2e0a32b51681fb356699b4a722f461f55a46b890 Change-Id: Ic0c60cd31bb6dabf03b0f8bd232390e784421588 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105017 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-28tdf#125379 updated javainteractionhandler.cxx to add a link for the JRE ↵Bryan Gazali
missing warning Change-Id: Iac940b24a9fbe914af46fe928b758ad962d3d3e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103881 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
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-28convert some more long -> tools::LongNoel
grepping for stuff in template params this time Change-Id: Ia37bfd85480b3a72c3c465489581d56ad8dde851 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104855 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-26rhbz#1891326 suggest package install of the most appropiate pt langpackCaolán McNamara
Change-Id: I87ff1a941a3a5dc0c321440a9c286ae73c9d0384 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104783 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-25Replace list by vector in svtools/sampletextJulien Nabet
Change-Id: I5ccff96e6369ff602e049dbaab1612574b729a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104750 Tested-by: Jenkins Reviewed-by: DaeHyun Sung <sungdh86+git@gmail.com> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-10-24Resolves: tdf#137703 crash on 2nd launch of cell bg color dropdownCaolán McNamara
Change-Id: I263edf36d70b3b81051c7aa5ca44523d0193975f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104719 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-22set all .ui min require version of gtk to 3.20Caolán McNamara
and update the version mentioned in our min req in the readme.xrm follow up to commit 0c9ccc7dbf6deb4d012e0d1e6eb934e54e0f19bc Author: Caolán McNamara <caolanm@redhat.com> Date: Fri Oct 2 21:21:45 2020 +0100 raise min version of gtk to 3.20.0 Change-Id: Ibae55c97e1ee577f4b7435d124cda6a21005ad0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104692 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-19use tools::Long in svtoolsNoel
Change-Id: I2b26da23e625e643dc2bb5393abff3671c457884 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104518 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-16add a DrawingAreaUIObject to avoid need to include layout.hxx for uitestCaolán McNamara
Change-Id: I2d7f9d38f9eac5af7b8b4d738335507beb6627df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104357 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-15need to ClearFormats to invalidate cache of what is dndedCaolán McNamara
Change-Id: I2280d1d883448f1a538a78acec0d1b7f04df5ffe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104326 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-12tdf#134742 Distinguishing all CJK fonts such as Noto CJK Fonts.DaeHyun Sung
Distinguishing both Korean and Japanese fonts from all CJK[Chinese-Japanese-Korean] fonts such as Noto CJK font series and Source Han Sans series, etc. For the first time, I added Hardcode script for "Noto" CJK fonts. The "Noto" CJK fonts support to Simplified Chinese, Traditional Chinese, Traditional Chinese HK, Japanese, and Korean (Pan-CJK fonts). Nowadays, Noto CJK Fonts are shown '简繁'. Noto font's KR(Korean, 한국어/한글) & JP(Japanese,日本語) represent Korean(KR, It shows '한글') and Japanese(JP, It shows '日本語'), respectively. These are not expressed in Chinese fonts, such as Simplified Chinese(简) and Traditional Chinese(繁). Also, Both TC(Traditional Chinese) and HK(Hong Kong) represent 繁. It don't shown 简繁. so, SC(Simplified Chinese) represent 简, It don't shown 简繁 So, I fixed Font select option's Noto CJK-series font Examples on LibreOffice Noto Sans CJK HK 简繁 -> Noto Sans CJK HK 繁 Noto Sans CJK JP 简繁 -> Noto Sans CJK JP 日本語 Noto Sans CJK KR 简繁 -> Noto Sans CJK KR 한글 Noto Sans CJK SC 简繁 -> Noto Sans CJK SC 简 Noto Sans CJK TC 简繁 -> Noto Sans CJK TC 繁 Noto Sans Mono CJK HK 简繁 -> Noto Sans Mono CJK HK 繁 Noto Sans Mono CJK JP 简繁 -> Noto Sans Mono CJK JP 日本語 Noto Sans Mono CJK KR 简繁 -> Noto Sans Mono CJK KR 한글 Noto Sans Mono CJK SC 简繁 -> Noto Sans Mono CJK SC 简 Noto Sans Mono CJK TC 简繁 -> Noto Sans Mono CJK TC 繁 Noto Serif CJK JP 简繁 -> Noto Serif CJK JP 日本語 Noto Serif CJK KR 简繁 -> Noto Serif CJK KR 한글 Noto Serif CJK SC 简繁 -> Noto Serif CJK SC 简 Noto Serif CJK TC 简繁 -> Noto Serif CJK TC 繁 However, It is only support to Noto CJK fonts and lack of distinguish fonts for all CJK[Chinese-Japanese-Korean) fonts. So, I think that change the code and improving the ability to distinguish fonts between Korean, Chinese and Japanese. 1. `remove Hardcode script for "Noto" CJK fonts 2. add hardcode script at attemptToDisambiguateHan(UScriptCode eScript, OutputDevice const &rDevice) and change distinguish among Korean, Japanese and Chinese fonts. Former - static const sal_Unicode aKorean[] = { 0x3131 }; - static const sal_Unicode aJapanese[] = { 0x3007, 0x9F9D }; - static const sal_Unicode aTraditionalChinese[] = { 0x570B }; - static const sal_Unicode aSimplifiedChinese[] = { 0x56FD }; Korean: U+3131 ㄱ Hangul Letter Kiyeok Japanese: U+3007 〇 Ideographic Number Zero & U+9F9D 龝 Traditional Chinese: U+570B Simplified Chinese: U+56FD That code’s problem Both Japaese kanji U+3007 〇 and U+9F9D 龝 also uses in Korean & Chinese. U+3007 〇 Definition: zero It uses in CJK(Chinese, Japanese and Korean) It usually uses number expression in MS Excel, LibreOffice. U+9F9D 龝 Definition: autumn, fall; year Mandarin Chinese reads qiū Korean Hanja sound is 추 chu Japanese Kun sound is ‘AKI' or ‘TOKI’ Japanese On sound is ‘SHUU’ That meaning likes ‘秋’. Korean [한자 너 어디 있었니?] 54. 분탕 焚蕩 http://www.incheonilbo.com/news/articleView.html?idxno=1019040 참고로 가을날 벼에 달라붙은 메뚜기 모양을 한 글자인 龝(추)는 秋의 고자(古字)로 서예가들이 멋을 부리기 위해 사용하기도 한다. Japanese 「龝」の漢字‐読み方・意味・部首・画数 - 漢字辞典 https://kanjitisiki.com/jis2/2-3/020.html 漢字の「龝」についてです。「秋」の異体字です。 Chinese 龝 - 中國哲學書電子化計劃 https://ctext.org/dictionary.pl?if=gb&char=%E9%BE%9D 《康熙字典·四》: 秋：〔古文〕龝《唐韻》七由切《集韻》《韻會》雌由切《正韻》此由切，音鰌。 Also, Both U+570B 國 and U+56FD 国 doesn't distinguish CJK languages. Because, 'U+570B 國’ uses in Traditional Chinese, Korean, Japanese texts. U+570B 國 Korean: 國 21國 정상급 26명 온다…평창서 `외교 올림픽` https://www.mk.co.kr/news/politics/view/2018/01/66693/ 핵융합발전 프로젝트 韓國이 주도..."ITER 부품의 70~80% 도맡아" http://www.dt.co.kr/contents.html?article_no=2020072802109931731004 Japanese: 國 ORANGE RANGE、母校の吹奏楽部・琉球國祭り太鼓とのライブを公開 https://news.yahoo.co.jp/articles/c6a7e9bb83e46662a8638cd5373a5c71d144cb8b Traditional Chinese: 國 國家森林遊樂區免費入園一次 上路一週最熱門是這地方 https://news.ltn.com.tw/news/life/breakingnews/3237355 Also, 'U+56FD 国’ uses in both Simplified Chinese and Japanese. U+56FD 国 Japanese: 国 日本人の子ども連れ去りは国ぐるみの誘拐？ 批准した国際条約、国内で適用せずは許されるのか https://www.47news.jp/news/5057377.html Simplified Chinese: 国 中国国际云书馆上线运行 http://world.people.com.cn/n1/2020/0726/c1002-31797808.html My suggestion to change code Changed + static const sal_Unicode aKorean[] = { 0x4E6D, 0x4E76, 0x596C }; + static const sal_Unicode aJapanese[] = { 0x5968, 0x67A0, 0x9D8F }; + static const sal_Unicode aTraditionalChinese[] = { 0x555F, 0x96DE }; + static const sal_Unicode aSimplifiedChinese[] = { 0x4E61, 0x542F, 0x5956 }; CJK language uses Ideographs(Chinese characters) in common. But, For Ideographs(Chinese characters) in the same sense, the shape and code points of Chinese characters are different for each country. Also. Some languages make Ideographs such as Korean-made Ideographs and Japanese-made Ideographs. I added Korean-made Ideographs & Japanese-made Ideographs & only use characters in Japanese. 1.Korean-made Ideographs: U+4E6D 乭 (It reads ‘돌 dol’ in Korean. It only uses in Korean) & U+4E76 乶 (It reads '볼 bol' in Korean. It only uses in Korean) 2.Japanese-made Ideographs: U+67A0 枠 (It reads ‘waku’ in Japanese. It only uses in Japanese) 3. only use in Korean & Japanese. U+596C 奬 It usually uses in Korean. U+5968 奨 & U+9D8F 鶏 These usually use in Japanese. The Traditional Chinese(繁體中文) form of prize, reward is U+734E 獎 The Simplified Chinese(简体中文) form of prize, reward is U+5956 奖 The Korean Hanja(한국 한자/韓國 漢字) form of prize, reward is U+596C 奬 The Japanese Kanji(日本 漢字) form of prize, reward is U+5968 奨 For example, Chinese characters(Ideographs) for Rooster The Traditional Chinese(繁體中文) form of the rooster is both 雞 (U+96DE) [It says jī ] & 鷄 (U+9DC4) The Simplified Chinese(简体中文) form of the rooster is 鸡 (U+9E21) [It says jī ] The Korean Hanja(한국 한자/韓國 漢字) form of the rooster is 鷄 (U+9DC4). [It says 계, revised romanization of korean is "Gyeo”] The Japanese Kanji(日本 漢字) form of the rooster is 鶏(U+9D8F). (It says とり[tori] , にわとり[niwatori]) Adobe CJK Type Blog - Year of the rooster https://blogs.adobe.com/CCJKType/2017/01/year-of-the-rooster.html 4. only use in Traditional Chinese U+555F 啟 & U+96DE 雞 The Traditional Chinese(繁體中文) form of open & begin is U+555F 啟 The Simplified Chinese(简体中文) form of open & begin is U+542F 启 The Korean Hanja(한국 한자/韓國 漢字) form & The Japanese Kanji(日本 漢字) form of open & begin is U+5553 啓 For example, Chinese characters(Ideographs) for Rooster The Traditional Chinese(繁體中文) form of the rooster is both 雞 (U+96DE) [It says jī ] & 鷄 (U+9DC4) The Simplified Chinese(简体中文) form of the rooster is 鸡 (U+9E21) [It says jī ] The Korean Hanja(한국 한자/韓國 漢字) form of the rooster is 鷄 (U+9DC4). [It says 계, revised romanization of korean is "Gyeo”] The Japanese Kanji(日本 漢字) form of the rooster is 鶏(U+9D8F). (It says とり[tori] , にわとり[niwatori]) 5. only use in Simplified Chinese U+4E61 乡 & U+542F 启 & U+5956 奖 The Traditional Chinese(繁體中文) form of country;rural;village is U+9109 鄉 The Simplified Chinese(简体中文) form of country;rural;village is U+4E61 乡 The Korean Hanja(한국 한자/韓國 漢字) form of country;rural;village is U+9115 鄕 & The Japanese Kanji(日本 漢字) form of country;rural;village is U+90F7 郷 The Traditional Chinese(繁體中文) form of open & begin is U+555F 啟 The Simplified Chinese(简体中文) form of open & begin is U+542F 启 The Korean Hanja(한국 한자/韓國 漢字) form & The Japanese Kanji(日本 漢字) form of open & begin is U+5553 啓 The Traditional Chinese(繁體中文) form of prize, reward is U+734E 獎 The Simplified Chinese(简体中文) form of prize, reward is U+5956 奖 The Korean Hanja(한국 한자/韓國 漢字) form of prize, reward is U+596C 奬 The Japanese Kanji(日本 漢字) form of prize, reward is U+5968 奨 So, I checked and built it. I found that distinguish among Korean, Chinese, and Japanese fonts from all CJK[Chinese-Japanese-Korean] fonts such as Noto CJK font series and Source Han Sans series, etc. Change-Id: Icc1f3ea31227f77c0e3ad0ec3ed03663deedee51 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99951 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-09inherit OStringTransferable from TransferDataContainerCaolán McNamara
so it can be used as an argument to weld: :CustomWeld::SetDragDataTransferrable Change-Id: Ibb58be6871a8719504d33d02bf7104213105be99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104126 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-06move set_user_managed_scrolling to an initial weld argumentCaolán McNamara
gtk is creating a11y objects on widgets changing parents so manage when that can happen to avoid premature creation of custom widget a11y objects Change-Id: I4879a93a897b2e4084cf6af0c9c0b0f0c1062254 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104025 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-06loplugin:const& make some params and methods constNoel
Change-Id: I2973128a9c6c53187e1da400d1a5df763d515596 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104020 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-04loplugin:reducevarscope in store..svtoolsNoel
Change-Id: Iaa6c6eac15cb73fc2a76ba1c5241297c94d297cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103839 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-03use more TOOLS_WARN_EXCEPTIONNoel
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-29tdf#136520 allow color popdowns to be tearable againCaolán McNamara
Change-Id: Ic92ef5235662e1680aadb5666e05dad1bf808e9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103625 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-28rename for disentangling AA and B2D use in VCL drawingLuboš Luňák
This renames AntialiasingFlags::EnableB2dDraw to just Enable, and the AntiAliasB2DDraw names to just AntiAlias. This is in preparation for a second commit that will actually separate the AA and B2D functionality of these flags. Change-Id: I9cc215c5752dfabce41e00e19d9074fc8dc3d4de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103416 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-24Related: tdf#115436 Add English (Kenya) {en-KE} to language listEike Rathke
Change-Id: I8f928533d52aa8ecc2567f6af45b85a860ff5da8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103302 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@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-19tdf#134157 fix Edit with external tool causes a CPU hitTomofumi Yagi
Switch Idle to 100ms Timer for fixing the bug Change-Id: I85a9bdcb173edd28d952d8e91c1b93d748e69206 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102984 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-17tdf#136737 grid in change icon dialog ends up oversizedCaolán McNamara
Change-Id: Ib3d28fc967bf5e1b95d71ebe42e1fc540ea91ac3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102923 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-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-12replace sal_IntPtr with simple integer typeCaolán McNamara
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-12tdf#136217 fix moving tag in writerNoel Grandin
regression from commit e67657d5211f6e95ddf8bd621108608573b00d5d loplugin:simplifybool more Change-Id: I4c62a7922734ea76ecec580491bfe8b0f62b781b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102514 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11invalidate prerendered fontname cache on style changeCaolán McNamara
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-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-10remove image_position top from GtkButtonandreas kainz
Change-Id: Ib7a8eb77b31a8abb08be501b1e0ce8d480f163c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102340 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-09-09tdf#134413 must add scrollbar width on turning it off to occupy the same spaceCaolán McNamara
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-09Resolves: tdf#136494 get preferred height after contents filled inCaolán McNamara
an empty widget appears to be less tall than one with content in the default Ubuntu theme Change-Id: I6b759b37d6706e6a4c3ded492d9c5b23f322e328 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102256 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-09tdf#135042 update scrolledwindow vadjustment when resizedCaolán McNamara
Change-Id: I94408845b82c7202f74360168c66c4439e985124 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102271 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-09improve loplugin:unusedvarsglobalNoel Grandin
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-07loplugin:constantparamNoel Grandin
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-04Make many OUString functions take std::u16string_view parametersStephan Bergmann
...instead of having individual overloads for OUString, OUStringLiteral, and literal char16_t const[N]. (The variants taking OUString are still needed for !LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char const[N] are also left in place.) This nicely reduces the number of needed overloads. std::u16string_view allows to pass as arguments: * OUString * OUStringLiteral * OUStringChar (with the necessary conversion added now) * OUStringNumber * u"..." char16_t string literals * u"..."sv std::u16string_view literals * std::u16string, plain char16_t*, and more A notable exceptions is OUStringConcat, which now needs to be wrapped in OUString(...), see the handful of places that needed to be adapted. One caveat is the treatment of embedded NUL characters, as std::u16string_view(u"x\0y") constructs a view of size 1, while only u"x\0y"sv constructs a view of size 3 (which matches the old behavior of overloads for literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16 machinery). See the new checkEmbeddedNul in sal/qa/rtl/strings/test_oustring_stringliterals.cxx. The functions that have been changed are generally those that: * already take a string of determined length, so that using std::u16string_view, which is always constructed with a determined length, is no pessimization (e.g., there are operator == overloads taking plain pointers, which do not need to determine the string length upfront); * could not benefit from the fact that the passed-in argument is an OUString (e.g., the corresponding operator = overload can reuse the passed-in OUString's rtl_uString pData member); * do not run into overload resolution ambiguity issues, like the comparison operators would do. One inconsistency that showed up is that while the original replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0) overload takes an optional third fromIndex argument, the existing replaceAll overloads taking OUStringLiteral and literal char16_t const[N] arguments did not. Fixing that required a new (LIBO_INTERNAL_ONLY) rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in sal/qa/rtl/strings/test_strings_replace.cxx). Another issue was posed by test code in sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that certain function calls should not compile (and would compile under RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to OUString as arguments). Those problematic "should fail to compile" tests have been converted into a new CompilerTest_sal_rtl_oustring. Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02use VCL_TOOLBOX_STYLE_FLAT directly instead of a define with the same valueCaolán McNamara
Change-Id: I025aafd0da19fb0382591545f3aa14e84c9c362e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101912 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02replace unnecessary includeCaolán McNamara
Change-Id: I799dcb6e7042e6d0174616458fa09b80ede59163 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101910 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-02weld TabBarEditCaolán McNamara
Change-Id: I513c81faa9b93fbcb7eb93ac60152dcc97b41481 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101585 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2025-02-09 17:31:57 +0000