Android-specific notes Unit tests are the first thing we want to run on Android, to get some idea how well, if at all, the basic LO libraraies work. We want to build even unit tests as normal Android apps, i.e. packaged as .apk files, so that they run in a sandboxed environment like that of whatever eventual end-user Android apps there will be that use LO code. Sure, we could quite easily build unit tests as plain Android executables, push them to the device or emulator with adb and run them from adb shell, but that would not be a good test as the environment would be completely different. They would run as root, and not sandboxed. We have no intent to require LibreOffice code to be used only on "rooted" devices etc. All Android apps are basically Java programs. They run "in" a Dalvik virtual machine. Yes, you can also have apps where your code is only native code, written in a compiled language like C or C++. But also also such apps are actually started by system-provided Java bootstrapping code (NativeActivity) running in a Dalvik VM. Such a native app (or actually, "activity") is not built as a executable program, but as a shared object. The Java NativeActivity bootstrapper loads that shared object with dlopen. It is somewhat problematic to construct .apk packages except by using the high-level tools in the Android SDK. At least I haven't figured out how to manually construct an .apk that is properly signed so that it will run in the emulator. (I don't have any Android device...) I only know how to let the SDK Ant tooling do it... A LO Android app would work would something like this: We have a top Java bootstrapping class org.libreoffice.android.Bootstrap that loads a small helper native library liblo-bootstrap.so that implements JNI wrappers for dlopen(), dlsym(), and ELF header scanning coresponding to looking for DT_NEEDED entries with readelf. The Java code then loads the actual native library that corresponds to the LibreOffice-related "program" we want to run. For unit tests, a library that corresponds to cppunittester program. Then through helper functions in liblo-bootstrap it calls a named function in that "program". This Android-specific code is for now in sal/osl/android. --Tor Lillqvist labora/cd-5.3-3.4'>distro/collabora/cd-5.3-3.4 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/svx/source/dialog/graphctl.cxx
AgeCommit message (Collapse)Author
2024-05-31svx: Reduce number of calls to GetMarkedObjectList()Xisco Fauli
from 447 to 208 Change-Id: I7b289b61a4ec416b9809f1433bb7a824ef488cb9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168227 Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-05-30AreObjectsMarked -> GetMarkedObjectList().GetMarkCount() != 0Xisco Fauli
In order to reduce number of calls to GetMarkedObjectList() later on Change-Id: Ib2eb7c88338e64744f886a338acca65f782f8170 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168218 Tested-by: Jenkins Tested-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-02-12ITEM: ItemPool Rework (I)Armin Le Grand (allotropia)
Driving forward the Item reworks I now take the ItemPool in focus: It now does not hold any items anymore and should be renamed to something like ItemInfoProvider/ItemHelper, since it's main purpose is to provide the Defaults for the Item functionality. There is that SfxItemInfo, only a struct and bundling SlotID and ItemFlags. There are also the DefaultItems, just handled as ptrs in an array. It is/was always error-prone to keep these in sync. Remember that it's also necessary for the order to not only being sorted but being increments of one with no gaps allowed in the WhichIDs to which the Items are bound. I now bundled that to a new class ItemInfo that joins WhichID, SlotID, ItemFlags and the default Item. This is a pure virtual base class, it comes in three derivations: (1) ItemInfoStatic: This is supposed to be global static and hosts the Item in a std::unique_ptr to ensure cleanup. It is designed to be constructed once during runtime and being shared globally. It allows the ItemPtr to be nullptr to mark as non-static (if initial static is not possible for some reason) but still offers the needed data. Most cases (95%+) are of that case. The contained Item is owned by that instance. The flag isStaticDefault() is set at the Item. (2) ItemInfoDynamic: This is supposed to be used for cases where the Item cannot be static: Mainly for SfxSetItem (that needs a Pool itself in the contained SfxItemSet, so lifetime is bound to that Pool), but other cases showed up in the transition. These instances live while the Pool lives and get destructed when the Pool goes down. Also uses std::unique_ptr for the Item instance for as much automated cleanup as possible, the contained Item is owned by that instance, the instance by the Pool. The flag isDynamicDefault() is set at the Item. (3) ItemInfoUser: This is used for UserDefaults that can be set for every ItemInfo entry to 'overshadow' the default from the 'outside'. It uses a regular Item and the central access methods implCreateItemEntry/ implCleanupItemEntry to manage the Item instance, thus works like a SfxPoolItemHolder. The Item instance can be globally shared and re-used even when the Pool goes down. Instances belong to the Pool and are cleaned up when the Pool goes down. This Item does not need any further flag to be set. The ItemInfos are organized using a class called ItemInfoPackage: This bundles groups of ItemInfoStatic to functional instances. There are derivations/ implementations of this e.g. for Writer ItemPool bundling all the needed defaults for Writer, similar for draw/impress, Calc and other usages. These ItemInfoPackage can be 'registered' at an ItemPool using it's method registerItemInfoPackage. This does all the needed stuff to setup that group of ItemInfos at the Pool (It even sets internal vars First/LastWhich, that info can just be derived from the buildup ItemInfo Ptrs). The ItemInfoPackage has methods 'size()' and 'getItemInfo(index) to allow looping over it and deliver the infos the Pool needs. The (forced, pure virtual) overloads of getItemInfo in the specific implementations check for the ItemPtr being nullptr and create a exclusive incarnation of ItemInfoDynamic for the Pool if needed, returning that. The Pool owns the ItemInfoDynamic incarnations and uses the ItemInfoStatic directly. On shutdown it cleans up the ItemInfoDynamic as needed. The ItemInfoUser is used by the Pool when a UserDefault is set/used: for SetUserDefaultItem, GetUserDefaultItem, ResetUserDefaultItem. It is not held in a 2nd list, but directly in the list of ItemInfo'ptrs: To keep track of this an unordered_map is used that helds the original ItemInfo associated with the WhichID. That way no two lookups (as before) are needed to get the current Pool's default for any WhichID. The derivations of ItemInfoPackage are encapsulated and just allow access to an ItemInfoPackage& with a single method as return value. All use a static local instance of a std::array<ItemInfoStatic, FIXED_SIZE> which constructs all ItemInfoStatic and the static Item instances - if already possible. Sometimes it is necessary to overload the constructor to set some static instances for Items later than the lib init. These are also just marked with nullptr as Item instance. Some need to overload getItemInfo to complete instances of ItemInfoStatic, if needed, or create and deliver instances of ItemInfoDynamic. The registerItemInfoPackage also offers a optional lambda callback: there were two cases where local data from the Pool was needed to incarnate the item - just add that to the call to registerItemInfoPackage if needed, see examples in the adapted code. For the re-use of Items this means that now in SfxItemSet/SfxPoolItemHolder *true* static Items can and will be used without RefCount directly and globally. This is also the case for dynamic Items, with the exception of differing Pools for SfxSetItems which cannot be done. Future: That design is already prepared to allow solving that Pool-chaining problem: currently there are master/sub-pools and all accesses have to traverse that structure before even doing anything. For the future the idea is more to 'compose' a Pool by registering ItemInfoPackages, e.g. for Writer pool you may start with SfxItemPool, register the writer-specific ItemInfoPackage, then the one for DrawingLayer (if needed) and the one for EditEngine. It should also be possible to get to smaller granularities of that packages. Ideas for new ones will emerge. We might also think about composing Pools which can e.g. run Writer and Chart, so allowing to use Chart *without* OLE stuff in Writer - just ideas... More changes: - Adapted all stuff, cleaned up old stuff/ definitions - Removed FreezeIdRanges, that can be done once per Pool on-demand (and cannot be forgotten to be called) - Merged XOutdevItemPool with SdrItemPool and offered a ItemInfoPackage which joins both needed sets of Items - All the cleanup hassle with Pools and defaults cleaned up - Adapted all access methods of the pool to use that new stuff. Pool chaining currently stays, but I use a central method 'getTargetPool' instead of recursive calling to get the correct Pool for the action Change-Id: I2b8d3d4c3cc80b1d0d0b3c0f4bd90d7656b4bab7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163157 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-07-12tdf#105362 better support for transparency in PNG & GIF exportArmin Le Grand (allotropia)
The granularity to decide at the SdrView what to paint was not fine enough, so I added code to get what we need: Do avoid page decorations (including PageBackgrund aka 'wiese'), but do include/process MasterPage content. Change-Id: I49df05abc89b4bcebc973c37d30be0a0c72e59ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154301 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-31svx: Refactor (sdr) views to access the SdrModel by referenceTomaž Vajngerl
In SdrPaintView (and subclasses) the mpModel variable is always the same as the input (reference) model, so there is no need for that extra variable. Change the strange and confusing var. name mrSdrModelFromSdrView (the input reference to SdrModel) to just mrModel and use that in GetModel(). Change the GetModel() to return a reference instead of a pointer and reactor the code to accomodate the change. This gets rid of many nullptr checks for the pointer that the GetModel() returns and makes the code more simple is some cases. Change-Id: I18351a417fd82f49262a83de036ec1420a65399c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146373 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-01-31SdrModel: we never set scale fraction to anything else than 1/1Tomaž Vajngerl
This removes the scale fraction on SdrModel - SetScaleFraction and the m_aObjUnit instance variable, as it is never set to anything else than 1/1 (and don't see it usefult to set it to anything else than this). Change-Id: I990d20f110b3be00e6770b68e39df212f9c576be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146348 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-01-20WASM --enable-wasm-strip now skips lots of LO codeArmin Le Grand (Allotropia)
... resulting in a stripped-down, Writer-only build to decrease the resulting WASM bytecode size. It removes the following code from the build: * All other major modules: Base, Calc, Chart, Draw, Impress and Math and related writerperfect filters * The premultiply tables * The (auto-)recovery functionality * All accessibility (but not the accessibility document checker) * The LanguageGuess component * EPUB support * The start center / BackingWindow * The TipOfTheDay functionality * The splash screen communication Currently crashs with anything different then soffice --writer. Closing the document also still crashes. FYI: many of these features are now behind ENABLE_WASM_STRIP_* defines, but they normally don't work on their own, globally! That's because we started with stripping the main components. Change-Id: Ib9c0f9452815910c0a2aceaf142ba1ad4a9cb0d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126182 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-07remove E3D_INVENTOR_FLAG and convert SdrObjKind to scoped enumNoel Grandin
We don't need E3D_INVENTOR_FLAG, we can just check if the SdrObjKind is in the right range. Which exposes some dodgy code in DrawViewShell::GetMenuStateSel SfxItemState::DEFAULT == rSet.GetItemState( OBJ_TITLETEXT ) || SfxItemState::DEFAULT == rSet.GetItemState( OBJ_OUTLINETEXT ) || which has been there ever since commit f47a9d9db3d06927380bb79b04bb6d4721a92d2b Date: Mon Sep 18 16:07:07 2000 +0000 initial import just remove that. In SwFEShell::ImpEndCreate() move some logic around to avoid using an out-of-range SdrObjKind value Change-Id: I4620bfe61aca8f7415503debe3c84bfe5f4368a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127763 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-20clean up ambiguous confusing rectangle APIs like IsInside()Luboš Luňák
Reading 'rectA.IsInside( rectB )' kind of suggests that the code checks whether 'rectA is inside rectB', but it's actually the other way around. Rename IsInside() -> Contains(), IsOver() -> Overlaps(), which should make it clear which way the logic goes. Change-Id: I9347450fe7dc34c96df6d636a4e3e660de1801ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122271 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins