starmath « es « source - lo/translations - LibreOffice 界面翻译代码仓库

Mode	Name	Size
-rw-r--r--	source.po	64773	log plain
d---------	uiconfig / smath	32	log plain

>Collapse)

Age	Commit message (Expand)	Author
Author
2024-11-30	tdf#130857 Search dialog: Use weld::Container ptr instead of Box	Michael Weghorn
	None of the weld::Box methods are used, so having a pointer to the weld::Container subclass is sufficient in the "Find and Replace" dialog implementation. Change-Id: I1219dd657ab8fb6067c90aabdc27b2b84c0a1443 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177577 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-10-20	tdf#163486: PVS: identical sub-expressions	Xisco Fauli
	Since commit 78010a4db197ac44fb729a122464847931ee0e5b Author: Caolán McNamara <caolanm@redhat.com> Date: Thu Oct 4 15:37:14 2018 +0100 Resolves: tdf#106340 resize dialog when search/replace labels are shown/hidden V501 There are identical sub-expressions '!m_xReplaceAttrText->get_visible()' to the left and to the right of the '\|\|' operator. V501 There are identical sub-expressions '!m_xReplaceAttrText->get_visible()' to the left and to the right of the '\|\|' operator. Change-Id: Ib62557af291679c253162e3d72a39659691ef0b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175285 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-08-27	Resolves tdf#162582 - Muted color for search info on dark themes	Heiko Tietze
	Change-Id: Ia4dddc05e0f90c4d3bca1ef8ab860b588743af3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172456 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2024-07-09	Resolves tdf#161568 - Feedback for QFS in floating mode	Heiko Tietze
	As band-aid for the lack of proper toolbar resizing, feedback is given via entry message type Change-Id: Ic2b2a2aff93040f558775d63c18c21370fabcb39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170167 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2024-06-11	ITEM: Change SfxItemSet to use unordered_set	Armin Le Grand (allotropia)
	With all the changes done for Items we can now do deeper basic changes to the ItemSet itself with manageable risk. I already did https://gerrit.libreoffice.org/c/core/+/166455 aka 'ITEM: Add measurements for SfxItemSet usages' to get some statistical information about the fill/usage grade of the ItemSet's fixed PtrArray to SfxPoolItems, check that out to get an own picture. Those results show that an average usage is between some extremes ranging from 0% to 50%, but when using more checks and using multiple files/interactions/edits in all applications we end up with around typical 12%-19% of that array used, the rest is nullptr's. Thus I thought about one of the initial ideas of this series of changes (ITEM), to use a std::unordered_map (A) instead of that fixed array of SfxPoolItem Ptr's (B). Tthat again was for a complete type-based rewrite, which I once did a POC, but the code cannot be adapted to that, just too much work. Those are very different in architecture, (B) is done since a long time (since ever), but as pointed out above, (A) is now possible. There are many aspects to it, let's grep some: Speed (iterate): (A) and (B) are both linear. (A) has less entries, but may touch different mem areas (buckets). (B) is linear, but many empty spaces which are usually uselessly iterated. Speed (access Item by WhichID): (A) is hashed by WhichID, so mostly linear for unordered_set/hash. (B) is in a linear array, but has to calculate the offset for each WhichID access. So I guess speed will mostly equal out. Memory: (A) will be dynamically allocated (buckets), but stl is highly optimized and may even re-use areas, has to provide some extra info but will need less places for Items since it's dynamic and can start empty. (B) will be allocated once (except AllItemSet) and may even be 'derived' to the ItemSet (SfxItemSetFixed), but has to allocate all space at once. I can go in lots of more detail here, but due to the results of the statistics I just made a test now, including measuring some results (will include in gerrit, not here). I used two pro versions for that. That way I have some data now. Result is: - It is now possible to do this, it runs stable :-) - Speed: As expected, mostly no change - Memory: Depending on usage, 0% to 25% less, usually around 8-10% Side effects: - SfxAllItemSet could be done without WhichRanges, thus without expensive 'merges' - SfxItemSetFixed is not needed. While the idea is good, it needs a lot of extra stuff - Access to Items is linear if set - WhichRanges: Still needed, but for vaildity checking/filtering of ItemSet content - WhichRanges: Worth to think about if these are needed at all, probably just exist for historical reasons since allocation/number of added Items was never ever dynamic -> just not allocatable Putting the current version on gerrit, may still trigger some UTs (checked SW/SC/SD...) I did not like that functionality at ItemSet that hands out a vector of the set items for cases where to avoid iterating and deleting items at the same time at an ItemSet, so changed to using a local vector of remembered WhichIDs and deleting after the iterator is done. I also saw some strange usages of SfxItemIter in sw which i will have to check. Since there are still problems with UTs which I can not reproduce locally I have now added asserts to the case that an ItemSet gets changed with still having active SfxItemIter(s). That is always an error, but with the architecture of that fixed array of ItemPtrs did not have devastating effects (purely by coincidence). With that asserts, UTs run well in SC and SD, but in SW I get 11 (eleven!) asserts from the UTs, all of them from 'ITEM: SfxItemSet ClearItem' BTW. I guess these have to be fixed before thinking about this change... Good news is that all 11 cases were the same in SW, in SwHistorySetAttrSet::SwHistorySetAttrSet which does some strange things using two SfxItemIter in parallel. Thus SW UTs are also clear and I see no more errors caused by ItemSets being changed while SfxItemIters are alive. Bad news is that I still have errors to hunt... NOTE: Have now cleaned all UTs, this showed that there are some unexpected side-effects of the Items being processed in another order when SfxItemIter is used, also found one case where a WhichRangesContainer is constructed for a SfxItemSet using the set items from another ItemSet and SfxItemIter to do so. There might be more cases not covered by UTs. NOTE: While speed stays the same and mem is reduced up to 25% (see measurements in 1st comment) another important aspect is that this frees the way for using ItemSets without WhichRanges - these are necessary mainly to create that fixed array of pointers to the Items in a manageable size. With a dynamic structure like unordered_set there is in principle no need anymore to use WhichRanges to pre-define the Items a Set could hold. There is one exception: We have cases where one ItemSet is set at another one with defined WhichRanges to filter the contained Items - these would have to be identified. This is a rare case and we would have to check cases where an ItemSet gets set at another ItemSet. This would be as if all ItemSets would be AllItemSets in principle - much easier for everyone. NOTE: Waited for 24.8 split just to not take unnecessary risks. Change-Id: I75b0ac1d8a4495a3ee93c1117bdf618702785990 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166972 Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> Tested-by: Jenkins
2024-05-11	loplugin:ostr in svx	Noel Grandin
	Change-Id: Ia765a03e033acb82e367873380d289587ea87d6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167449 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-02	WaE: C6011 Dereferencing NULL pointer warnings	Caolán McNamara
	Change-Id: I8edb1fefe1b2b8a3db3ee8f3a0eed59c7f08a36e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166863 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-04-03	tdf#146619 Drop unused 'using namespace' in: svx/	Gabor Kelemen
	Change-Id: Ic8b925a3ec55166a9d5da05827d2cb335943b665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165542 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
2024-03-26	ITEM: Use SfxPoolItemHolder in SvxSearchDialog	Armin Le Grand (allotropia)
	I replaced that SfxPoolItem* in SearchAttrInfo with a much safer SfxPoolItemHolder and adapted and simplified used code - it does not need to take care of Item lifetime/Cloning itself. That works well. I did not find out why that 'invalid' state is used in the SrchAttrInfoList, but seems to be needed. Thus I keep this for now as it is (it can be all expressed/used using SfxPoolItemHolder, too). Change-Id: I4b769f43128cb2e25153919f7652b2f032393123 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165167 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-03-21	ITEM: Remove InvalidateAllItems()	Armin Le Grand (allotropia)
	I checked if this is used, but it can be replaced using Clear() -> all. This prevents that the whole array of Items in an ItemSet gets set to INVALID_POOL_ITEM. I also checked if INVALID_POOL_ITEM/IsInvalidItem is needed at all representing SfxItemState::DONTCARE but it is and still will need to be set for individual Items. At last checked if SfxItemState::UNKNOWN and ::DISABLED really need to be separate states, but indeed there are some rare cases that need that. To make things more consistent I also renamed SfxItemState::DONTCARE to SfxItemState::INVALID to better match Set/IsInvalid calls at ItemSet. The build showed a missing UT and led to a problem due to the hand-made ItemSet-like SearchAttrItemList. The state 'invalid' seems to be used as 'unused' marker. It should be changed to use SfxPoolItemHolder and not need that. For now, set by using an own loop to set to that state. Change-Id: Ifc51aad60570569a1e37d3084a5e307eed47d06c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165035 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2024-02-18	ITEM: Rename for more control over SlotID usages	Armin Le Grand (allotropia)
	Change-Id: I51585f1c15984a066262023184f668662853d20f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163556 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-12-30	tdf#146619 Recheck svx/ with IWYU	Gabor Kelemen
	Change-Id: I99650b50587294c20b1e92270e541140d9ec9cae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161240 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-21	Remove DeleteItemOnIdlex	Armin Le Grand (allotropia)
	There are some CrashReports in 7.6 which have DeleteItemOnIdle on the stack, but there is nothing reproducable. So I took a look... I first thought it's a MCGR regression, due to classes on the stack. But the Item involved is just random, can happen with any Item. Then I thought it may have to do with ITEM refactorings, but it happens with DeleteItemOnIdle involved, so also not the case. I already saw DeleteItemOnIdle when doing these and qualified as 'hack' in the way. already It is only on Windows and DeleteItemOnIdle is involved. This again (took a deeper look now) is an old hack to keep an SfxPoolItem 'alive' for some 'time'. For that, it triggers an async reschedule which then deletes the Item when being called. If the Item will be used after that is pure coincidence - seems to work in most cases. It seems as if for Windows the timing slightly changed for some scenarios, so a reschedule is too early. This can happen with this hack anytime. DeleteItemOnIdle is used in scenarios where SfxPoolItem* is e.g. returned, but is not anchored, so e.g. not member of an SfxItemSet. Or in short: Lifetime is not safe. DeleteItemOnIdle exists since 1st import, but was changed to AsyncEvent ca. 4 months ago (see 57145acf9ec47c23e307b7a5c0029d21d937cc35), so that may have caused it. It is possible that these errors happen on Windows since then. Before something more complicated was used to delete it late, but surely also not really safe. Due to ITEM refactor I have the knowledge/tooling to solve this. It will not be a 1-5 lines fix, but it is a hack and in the way for further ITEM refactor anyways. What we have nowadays is a SfxPoolItemHolder -> it's like an SfxItemSet for a single Item. It safely holds/ controls the lifetime of an SfxPoolItem. It is already used in quite some places. It helps to solve many hacks, also the ones putting Items directly to the Pool - due to there never was an alternative for that. In principle the ItemPool/ItemSet/Item paradigm was never complete without SfxPoolItemHolder. Thus I started to fix that (and remove that hack for good, sooo many changes over the years, sigh), but as said is not straightforward. Will have to change retvals of involved stuff to SfxPoolItemHolder - it's just two pointers and designed to be copied (one is a Pool, needed to cleanup when destructing). CopyConstruct/destroy just counts the RefCnt up/down, so cheap. 1st version compiling, let's check on gerrit... Corrected one error in QueryState for securitypage, also added some security features/asserts. Change-Id: Ida49fd35ca88ead84b11d93e18b978cb9e395090 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161083 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-11-28	Related tdf#156227 - Find/quickfind design	Heiko Tietze
	Themed icons look bad when drawn white on light blue; using the same icon as on the infobar makes more sense Change-Id: I6b4fd2bac7dce41b8196c702e0f0dc87712e2b8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160017 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2023-10-28	Resolves tdf#156227 - More appealing feedback for find/quickfind	Heiko Tietze
	ErrorMessageType removed in favor of an infobar-like label Accessibility notification added for the quickfind bar Change-Id: Iec2498d04152392b3e181146005bdb0c9db8ec50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156943 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
2023-10-10	jsdialog: hide help and close buttons for searchreplace dialog	Pedro Pinto Silva
	Signed-off-by: Pedro Pinto Silva <pedro.silva@collabora.com> Change-Id: I0f3bc2cd6839c74dff40431f8659d7f90b285d12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149293 (cherry picked from commit c65142fd9fd9a43e1f27cb11f5b4048600b5a4c4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157720 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-08-18	ITEM: preparations for more/easier changes	Armin Le Grand (allotropia)
	This change is not about speed improvements but diverse preparations to make changes/reading/understanding easier. It does not change speed AFAIK. Added a global static debug-only counter to allow getting an overview over number of all allocated SfxPoolItem's and the still alloated ones at office shutdown. The values are used in Application::~Application to make a short info statement. It allows to be able to quickly detect if an error in future changes may lead to memory losses - these would show in dramaitically higher numbers then (hopefully) immediately. Moved SfxVoidItem to own source/header. Added container library interface support to SfxItemSet, adapted already some methods to use it - not all possible, I will commit & get status from gerrit 1st if all still works and then continue. Changed INVALID_POOL_ITEM from -1 to use a global unique incarnation of an isolated derivation from SfxPoolItem. It allows to avoid the (-1) pointer hack. Since still just pointers are compared it's not worse. NOTE: That way, more 'special' SfxPoolItem's may be used for more States - a candidate is e.g. SfxVoidItem(0) which represents ::DISABLED state -- unfortunately not only, it is also used (mainly for UI stuff) with 'real' WhichIDs - hard to sort out, will have to stay that way for now AFAIK. Changed INVALID_POOL_ITEM stuff to use a static extern incarnated item in combination with a inline method to return it, called GetGlobalStaticInvalidItemInstance(). Isolated create/cleanup of a SfxPoolItem entry in SfxItemSet to further modularize/simplify that. It is currently from constructor & destructor but already shows that PoolDefaults are handled differently - probably an error. Still, for now, do no change in behaviour (yet). Got regular 'killed by the Kill-Wrapper' messages from gerrit, seems to have to do with UITest_sw_findReplace. That python/c++ scripting stuff is hard to debug, but finally I identified the problem has to do with the INVALID_POOL_ITEM change. It was in SfxItemSet::InvalidateAllItems() where still a (-1) was used -> chaos in detecting invalid items. Change-Id: I595e1f25ab660c35c4f2d19c233d1dfadfe25214 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155675 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-08-07	ITEM: speedup WhichRanges access by buffering	Armin Le Grand (allotropia)
	I checked for was to speedup SfxItemSet stuff, so had (besides other things) a look at WhichRangesContainer and it's usage(s). Problem with the WhichRanges is that a WhichID which you try to find is usually inside that range, so binary search is no option. You have to detect in which range the WhichID is hosted and can the directly calculate the index into the array of Items at the SfxtemSet. Currently when needing to transform a WhichID to an index into the array of Items in SfxItemSet the array of the WhichRangesContainer is searched linearly from the start every time. This can be a little bit speed up by buffering the last successful 'hit' and trying to re-use it. Also the special case of a single WhichPair (e.g. UI stuff) is worth having a look. All acesses to that transformation are changed to use the tooling method getOffsetFromWhich() at the WhichRangesContainer which does the transformation. This also needed cleanup of ItemOffsetHint instances & stuff around it. It does not more than before but also profits from the single entry buffer. I added some DBG_UTIL-based stuff to watch the hit/miss ratio, which is heavily changing from app to app & usage, but varies around 1.5 to 3.5, also saw 6.5 and more at document import. NOTE: I already checked if sorting the WhichPair(s) in WhichRangesContainer by their 'width' (highest WhichID mnius lowest WhichID helps. The idea was when the Items would be used in a regular manner that when having the widest WhichPairs at the start, the buffer would even be better used - but doing tests in all apps shows nearly no gain, so I left that out. NOTE: Not too much speedup, but faster... Had to deep-debug due to CppunitTest_sw_odfexport failing, found a slight diff between GetItemState impls, corrected. Also added more changes, e.g. TotalCount is now a member to not always have to calculate it from the WhichRangesContainer. Extended GetWhichByPos to 1st try to find a set Item, else iterate over WhichRangesContainer. This is due to SfxItemIter's implementations of GetItemState and ClearItem which both up to now just accessed the SfxPoolItem array of the SfxItemSet, ignoring that no Item (nullptr) or state DONTCARE (-1) may have been set there (no item is prevented by ite Iterator, but better be careful). Added WhichRangesContainer::getWhichFromOffset and made SfxItemSet::GetWhichByOffset use it. Addedd optimizations there for single-entry WhichPair and using the buffer at WhichRangesContainer which is possible. Removed debug comparing stuff (had a test that used the former adapted GetItemStateImpl method in SfxItemSet::GetItemState and compared with the changed GetItemState_ForWhichID). Added some comments and assertions where useful. Made ClearSingleItem_ForOffset work without handing over WhichID, that makes calls using it simpler and avoids calculating the WhichID just for that call. Change-Id: I54de552368b654f00f115978715f8241eb603752 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155316 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-06-07	tdf#155376 partially convert SvCTLOptions to officecfg	Noel Grandin
	When accessibility is enabled, Calc will add tens of thousands of listeners. We then spend a significant chunk of time creating SvCTLOptions objects (attached to ImpEditEngine) and adding and removing those objects from the related listener lists. But the required information is already globally cached by the officecfg module, so we can avoid that overhead and just fetch it directly from officecfg. Change-Id: I7ff55fd7c4926866eb7086812275ba8bd6e84c75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152645 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-29	use more TypedWhichId	Noel Grandin
	Change-Id: If7b4320e199a01f2614e3bf582e5d96fade22aa2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152353 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-19	tdf#154818 - Find bar: remember and reuse last search string	Andreas Heinisch
	In addition, the search items are rearranged to their usage order. Change-Id: I4f4bdfd869a981726ef84060e93c178502eaefef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150485 Tested-by: Jenkins Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
2022-09-26	tdf#119788 tdf#117173 add accessibility NOTIFICATION role	Jim Raykowski
	and use it to make screen readers announce notifications from the 'Find and Replace' dialog Change-Id: Ifcf9304883e2e824ea1b7998d7767e474b87c8b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139709 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2022-09-05	tdf#117173 make search label read by screen reader	Jim Raykowski
	Change-Id: I3ced9f5f3637e8489d0512b48882724a5a51b577 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137913 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-06-22	crashreporting: apparent null derefs of SfxViewFrame::Current()	Caolán McNamara
	Change-Id: I0e2c07a7eaa0a13be0a44c7cd187feec8ed4c2c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136277 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-01	Fix typos	Andrea Gelmini
	Change-Id: I9a98bac7c570f25ff7d77df98e93aaeed2665038 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130720 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-12-03	tdf#129629 sw UI: Find/replace - stop popping open MORE section	Justin Luth
	This was a regression from LO 6.1, where it would always show the "more" options if one of them was enabled. That might be fine for the dialog initialization (and that is how I implemented it) but even that is a bit much. Perhaps it should be a search option that is remembered while the application is running. Is that what pSearchOptions holds? Anyway, this much I can easily figure out. Someone who knows more about these things can enhance it further if they want. Change-Id: I8288bea514840f4ea06deb00a3603aa9568a75b7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126226 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2021-10-12	loplugin:moveparam in various	Noel Grandin
	Change-Id: Ifa7c8ff2b21f63d234c29c28303d0bacd376c1e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123434 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-28	gives names to all the Idles and Tasks	Noel Grandin
	enforce it by making the constructor parameter non-default. Change-Id: I321543e4dcf15ea0a43ad8cce91d2f8dc22df6ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122766 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>