Age | Commit message (Collapse) | Author |
|
Change-Id: Iab23e399f2650ece702fb1f62d1387acca472b42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107480
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ida7d7419f0513624071b31820660add93ac78615
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106445
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I493e241e590325306a59fda89a30f1c97410c373
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106180
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after fe3dd6d831998dd5619ea223af04bc51f9294d2f "Changed return type of
GetHTMLColor". (Clients had already been updated with
530df0b322f64fdcb08e9ef0b6ba944dd172ef60 "Changed return type of GetHTMLColor"
and 463563853a81499de2259372755b00aa5ec246a7 "Changed return type of
GetHTMLColor".)
Change-Id: I1db842775a69bb3c0ff08dca152094d7b67ca221
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106177
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia573921566ec6079b843cbcc0401d9d0f5c62089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105969
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There is no way to set the minimum height by the UNO API.
Therefore the requested size will be reduced.
Change-Id: Ie657518a83ffb6873e4fd2a5640580b5198a38d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105566
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I56a49c7fec128eb47818ee664acf01434d24f88d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105715
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
... broken since tools::Long is 64-bit on that platform, and thus
Point and Size are not equal to POINTL and SIZEL.
Change-Id: I8cf53f778ece89415687c6966d8e079fb0cf6189
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105910
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
for a in `git ls-files '*.ui'`; do sed -i 's/^\( *\)\(<object class="GtkGrid".*\)/\1<!-- n-columns=1 n-rows=1 -->\n\1\2/' $a; done
so we get the same behavior in glade as before 3.38 in that the grid preview
don't show any unoccupied grid squares
replace all existing n-columns=X n-rows=Y lines because they are
all wrong, except for
cui/uiconfig/ui/additionsfragment.ui
sw/uiconfig/swriter/ui/pageheaderpanel.ui
sw/uiconfig/swriter/ui/pagefooterpanel.ui
which are correct.
Change-Id: I401bbe8e098c26e7f57d6a872d3b70fc1ce85a00
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105846
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...to "Find functions that take rtl::O[U]String parameters that can be
generalized to take std::[u16]string_view instead." (Which in turn can avoid
costly O[U]String constructions, see e.g. loplugin:stringview and subView.)
Some of those functions' call sites, passing plain char string literals, needed
to be adapted when converting them.
Change-Id: I644ab546d7a0ce9e470ab9b3196e3e60d1e812bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia1b99ed420daf5d238082f374eab7b76920714f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105167
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I2a8d4f401ddfd4368a7b50b4c3c8a72724f9afa3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105154
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I92a42eb2ff48bff4e635f1a37a25c8ecb9ac1347
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105153
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id80ba8a87af7f87b8232949b70804b1a021b23d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105147
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1419af229a67d6ebb1cf2c63757656beb3f512db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105142
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0e0bdc925f106884cbcede6405cc6ef7152ad405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105139
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: Ia7aa2c5fa4d6bbe5cd722d8e27ec1a10c36fc4e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105028
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ide9811c1a7582454b3fcf655b70ea106ed56509a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104914
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I87ff1a941a3a5dc0c321440a9c286ae73c9d0384
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104783
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
Change-Id: I263edf36d70b3b81051c7aa5ca44523d0193975f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104719
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
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>
|
|
Change-Id: I2b26da23e625e643dc2bb5393abff3671c457884
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104518
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2d7f9d38f9eac5af7b8b4d738335507beb6627df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104357
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I2280d1d883448f1a538a78acec0d1b7f04df5ffe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104326
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I2973128a9c6c53187e1da400d1a5df763d515596
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104020
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaa6c6eac15cb73fc2a76ba1c5241297c94d297cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103839
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8b5cde993c13e0b7c8c830b1ff698933a6b7cfd0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103863
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic92ef5235662e1680aadb5666e05dad1bf808e9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103625
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
Change-Id: I8f928533d52aa8ecc2567f6af45b85a860ff5da8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103302
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
Change-Id: Ib3d28fc967bf5e1b95d71ebe42e1fc540ea91ac3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102923
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...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>
|
|
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>
|
|
Change-Id: I5aaf606b684b69641a872b3405b4d4d378289ad4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102466
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
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>
|
|
Change-Id: Ie2111f23dc3346b914442090e3d9257c5659fafc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102459
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|