summaryrefslogtreecommitdiff
path: root/librelogo
AgeCommit message (Expand)Author
2014-03-31fdo#75109 librelogo: fix localized proceduresLászló Németh
2014-03-18librelogo UI fixes, gradients, log10, improved random colorsLászló Németh
2014-02-04librelogo: keep comments at translationLászló Németh
2014-01-30LibreLogo is not a UNO componentStephan Bergmann
2014-01-08Remove bad Emacs mode lineStephan Bergmann
2014-01-08Some ConfigurationProvider -> theDefaultProvider simplificationsStephan Bergmann
2014-01-07librelogo: fix messagebox (API changes)László Németh
2014-01-01fdo#73199 librelogo: path, interop. and color name fixesLászló Németh
2013-10-28gbuild: set Package default target to INSTDIRMichael Stahl
2013-10-28fdo#70951 librelogo: fix parsing problem of functionsLászló Németh
2013-10-25fdo#70858 librelogo: fix Logo program halt at font settings (Windows)László Németh
2013-10-25librelogo: fix division with measurementsLászló Németh
2013-10-24librelogo: more invisible settings (on UI, hatching), see ChangeLogLászló Németh
2013-10-24librelogo: fix Writer/Draw synchronization in cropped SVG exportLászló Németh
2013-10-24librelogo: fix blinking LABELLászló Németh
2013-10-23librelogo: support linecap settingsLászló Németh
2013-10-23librelogo: optional SVG/SMIL looping (at ending SLEEP)László Németh
2013-10-22librelogo: fix black (not refreshed) invisible filling colorLászló Németh
2013-09-23Try to fix cross-compilationTor Lillqvist
2013-09-11Towards a working instdir for Mac OS XStephan Bergmann
2013-09-06fdo#69041 LibreLogo: fix SVG/SMIL timing with filled polylinesLászló Németh
2013-08-29LibreLogo fixes (eg. fdo#68713 fix SVG cropping), see ChangeLogLászló Németh
2013-08-18Further work on the "Mac-like app structure" optionTor Lillqvist
2013-07-18librelogo: fix LibO SVG export for W3C Validator/WikipediaLászló Németh
2013-07-16fix misleading typos in librelogo/changelogLászló Németh
2013-07-15librelogo: hexa arguments fdo#66917 and cropped SVG savingLászló Németh
2013-07-10added FIXME-BCP47 commentEike Rathke
2013-06-26fdo#66180 librelogo: clockwise HEADINGLászló Németh
2013-06-26fdo#66180 librelogo: clockwise HEADINGLászló Németh
2013-04-30fdo#64082 logo: fix hide/showturtleLászló Németh
2013-04-21Some changes in qtz handlingZolnai Tamás
2013-04-15fdo#60724 correct spellingThomas Arnhold
2013-04-14install librelogo using filelistsDavid Tardon
2013-03-25Remove unneeded project and projectroot parametersZolnai Tamás
2013-03-14remove legacy build.pl prj/build.lst files.Michael Meeks
2013-02-28remove all d.lstMichael Stahl
2013-02-24fdo#61376 librelogo: fix missing Asian and CTL support, etc.László Németh
2013-02-07fdo#60406 librelogo: fix name conflict in procedure handlingLászló Németh
2013-01-29fdo#59969 crash fix (insecure clear screen during Logo execution)László Németh
2013-01-29minor librelogo fix: remove ro lang. guess. (fix en_US detection)László Németh
2013-01-26gbuild: fix silly "expandtabs" in makefile VIM modelinesMichael Stahl
2013-01-22librelogo: start selected text; am, eo transl. sup.László Németh
2012-12-30add runtime deps for custom targetsDavid Tardon
2012-12-26librelogo fixes, ca/cs/et/pt_BR/ro lang. guessing for translationLászló Németh
2012-12-17LibreLogo: fixes for the Slovenian and other localizationsLászló Németh
2012-11-29add dep on .po fileDavid Tardon
2012-11-29add missing dep on propexDavid Tardon
2012-11-29LibreLogo: fix typoLászló Németh
2012-11-29LibreLogo: fix Python 3 supportLászló Németh
2012-11-28LibreLogo integration (extension -> normal code)Andras Timar
generated by cgit (git 2.34.1) at 2025-03-08 23:50:45 +0000
ve all items in the SfxItemSet, no longer at the Pool. The Pool should be reduced to a 'Default-Item- Holder' and a 'Slot-to-whichId-mapper'. This needs thorough cleanups/removals, but will be worth it because that massive simplification(s) will increase safety an runtime and make migrating to the goal of completely type-based ItemSet stuff easier for the future. Hopefully only view code in the office working with items will have to be changed for this. In this 1st step I already found that some 'compromizes' will be needed: - There are still Items that have to be at the pool to make the Surrogate-stuff working. This gives back all Items in a Pool of a type and is used in ca. 80 cases. Each one looks at these Items *without* context (e.g. a SfxItemSet at an Object would be a context), so if e.g. a dialog is open that temporarily uses Items of that type you would also get these - without knowing about it... To make that work there is still a mechanism to have Items at the Pool, but now just *registering* (and un-reg) them without any sort/search/ remove needs. Also only for Items that need that, so I evaluated the GetItemSurrogates calls and added some asserts when GetItemSurrogates tries to access an unregistered item type which needs to be added. - Another caveat is that there are about 250 places that directly put Items to the Pool (not all remove these, that is done at pool deletion, so some kind of silent 'garbage-collection' is in place). To have an overview I renamed the accessing methods to separate them from the same functionality at the SfxItemSet, which had the same names. An implementation does still add these directly to the pool, there is no way to cleanup those usages for now. In principle all these should be changed to hold the data at an SfxItemSet. I am still hunting problems. But you can build the office, all apps work (including chart) and you can do speed comparisons already. There are test throwing errors, so I hunt these now. It is hard to give an estimation about how much more changes/corrections will be needed. Completed adaptions to new registered Items at Pool, that reduces the failing tests. Still many that I need to hunt. Added stuff to work around that 'compromize' in ScDocumentPool: It overloads ::PutImpl of the pool to implement special handling for a single Item in SC, the ScPatternAttr. In former code that method was used from SfxItemSet and ::PutImpl at the pool directly, so it was only used in one place. I am not sure if it was used from the SfxItemSet functionality, but better offer it for now. To not waste too much runtime the callbacks depend on the boolean 'NewItemCallback' at the SfxPoolItem, it gets set for that single Item in SC and only then the callbacks trigger. I hope to get rid of those again, e.g. newItem_UseDirect is only needed since we have no 'real' StaticPoolDefaults currently - another thing that needs to be cleaned up in a next step. Since usages of impl(Create|Cleanup)ItemEntry and Direct(Put|Remove)ItemInPoolImpl got more and more similar I decided to unify that: move impl(Create|Cleanup)ItemEntry to tooling, make it globally available in svl and use it also directly for Direct(Put|Remove)ItemInPoolImpl. This slightly increases the failing tests again, but only since in Direct(Put|Remove)ItemInPoolImpl that fallback (e.g. tryToGetEqualItem) was used before, thus this is the same class of errors (SfxPoolItem ptr-compare) as the others which I will need to find anyways. Also fixed some missing stuff. Have now idenified and redirected all SfxPoolItem ptr-compares to be able to debug these - one cause for the remaining errors is probably that before with bPoolable those often were sufficient, but are no longer. Used the [loplugin:itemcompare] and a local clang build to do so, see https://gerrit.libreoffice.org/c/core/+/157172 Stabilized Direct(Put|Remove)ItemInPoolImpl forwards, added parameter to implCreateItemEntry to signal that it gets called from DirectPool stuff - currently needed. Hopefully when getting rid of that DirectPool stuff we can remove that again Added two more debug functionalities: - Added a SerialNumber to allow targeted debugging for deterministic cases - Added registering & listing of still-allocated SfxPoolItems at office shutdown Found PtrComp error in thints.cxx - POC, thanks to areSfxPoolItemPtrsEqual. Will hopefully help more with other tests Found some wrong asserts/warnings where I was too careful and not finding something/succeeding is OK, fixes some UnitTests for SC For SC I now just tried to replace all areSfxPoolItemPtrsEqual with the full-ptr-content compare SfxPoolItem::areSame. I also needed to experiment/adapt the newItem_Callback solution but got it working. Did that replacement now for SW too, found some places where the direct ptr compare is OK. Continued for the rest of occurrences, now all 160 places evaluated. Also done some cleanups. Massive cleanups of stuff no longer needed with this paradigm change. Also decided to keep tryToGetEqualItem/ITEM_CLASSIC_MODE for now. It is used for *one* Item (ScPatternAttr/ATTR_PATTERN) in SC that already needs many exceptions. Also useful for testing if errors come up on this change to test if it is related to this. Added forwarding of target Pool for ::Clone in SvxSetItem and SvxSetItem, simplified SfxStateCache::SetState_Impl and returned to simple ptr compares in SfxPoolItem::areSame to not do the test in areSfxPoolItemPtrsEqual. Debugged through UITest_calc_tests9 and found that in tdf133629 where BoxStyle is applied to fully selected empty calc the Item- reuse fallback has to be used not only for ATTR_PATTERN, see comment @implCreateItemEntry. Maybe more... Problem with test_tdf156611_insert_hyperlink_like_excel. Found that in ScEditShell::GetFirstURLFieldFromCell the correct SvxURLField is found and returned as ptr, but it's usage crashes. That is due to the SfxItemSet aEditSet used there gets destroyed at function return what again deletes the SvxFieldItem that is holding the SvxURLField that gets returned. This shows a more general problem: There is no 'SfxPoolItemHolder' that safely holds a single SfxPoolItem - like a SfxItemSet for a single Item (if Items would be shared_ptrs, that would be a safe return value). That will be needed in the future, but for now use another solution: Since I see no reason why EE_FEATURE_FIELD should not be shareable I wil change this for ow in the SfxItemInfo for EditCharAttribField. That way the Item returned will be shared (RefCnt > 1) and thus not be deleted. I changed the return value for GetURLField() and GetFirstURLFieldFromCell() in ScEditShell: At least for GetFirstURLFieldFromCell the return type/value was not safe: The SvxFieldItem accessed there and held in the local temporary SfxItemSet may be deleted with it, so return value can be corrupted/deleted. To avoid that, return a Clone of SvxFieldData as a unique_ptr. With all that UnitTest debugging and hunting and to get the paradigm change working to no longer rely on shared/pooled items I lost a little bit focus on speed, so I made an optimization round for the two central methods implCreateItemEntry/implCleanupItemEntry to get back to the speed improvements that I detected when starting this change. It was mainly lost due to that 'strange' chained pool stuff we have, so I added to detect the target pool (the one at which the WhichID is registered) directly and only once. Next thing to cleanup will/should be the pool and it's concept, all this is not needed and really costs runtime. Since implCreateItemEntry/implCleanupItemEntry are executed millions of times, each cycle counts here. Had an error in the last changes: pool::*_Impl methods use index instead of WhichID - most of them. Another bad trap, I really need to cleanup pool stuff next. Change-Id: I6295f332325b33268ec396ed46f8d0a1026e2d69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157559 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com> 2023-03-29fix concurrent access to fontcacheNoel Grandin Every now and then I see a crash in fontcache code. Add some DBG_SOLARMUTEX calls there, which spots a few issues. (*) In writer, SwDLL needs to be under the SolarMutex during init, and we can just move a method call to fix that. (*) in chart2, life is more complicated. Various of the static defaults we build want to call OutputDevice::getFontInstance. We can't just stick a SolarMutex somewhere in the call chain, because those maps are built on-demand, and then we end up with ABBA deadlocks between the SolarMutex and the mutex in the cppu::PropertySetHelper. So I picked a spot that is init'ed early on in chart2, and force the init of all the troublesome tables there. Change-Id: I832978bea35fd5fa681d144b8beff1af13ef3341 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149648 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-12-01tdf#145599 Charts gets corrupted when you draw a line inside themNoel Grandin This reverts commit 2ed8c34bca56c1a30d727b21d9096cb77e88197a use a single global item pool for chart2 draw model Change-Id: I640a981a2cbbed1cb9e6c0b0c239c78bb481e12e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2022-08-14chart2: add UI to the data tableTomaž Vajngerl This adds a new object type "Data Table", with all the object identifiers and converters of properties. The data table is now shown in the drop-down of chart elements. A properties dialog was added, which allows to change properties of a data table. This contains the area, line and font tab pages and a new tab page specific for data tables, to change if the horiz. or vert. borders, key or the outline should be show. Change-Id: I9b4cd58cffbcc952daaa2c0c8f8a5a17e38ac293 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138246 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> 2022-01-13Recheck modules [a-c]* with IWYUGabor Kelemen See tdf#42949 for motivation Change-Id: I74a3c3a67c3639376e2251c3eb917fa4139dfbd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127808 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>