| Age | Commit message (Collapse) | Author |
|---|
|
TB lo_daily_tb_linux_wasm shows:
/home/tdf/jenkins/workspace/lo_gerrit/tb/src_wasm/chart2/source/controller/main/ChartController.cxx:1557:71: warning: unused parameter 'rAccChartView' [-Wunused-parameter]
void ChartController::impl_initializeAccessible( AccessibleChartView& rAccChartView )
^
1 warning generated.
Change-Id: If584e6944c1d9105a7a8b7170dc1022911b57bf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159373
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
To understand this, some look back in history will be needed to see
why it is as it is today. In some (reworked) comments 'poolable' is
described as flag to hold Items in the ItemPool, also always having
only one incarnation of each possible Item.
This is not the original intention, but a side-effect. The reason is
what the binary format in the office did: To save a document, the
Objects & the Pool were saved, *not* individual Items *together*
with the objects. The Pool was completely (binary) saved (and loaded)
in one run.
Temporary IDs were used to represent at the objects in file which
Items were referenced. This *required* to have only one incarnation
per item to have a minimal binary file size, thus this high effort
was put into this. At doc load, the pool was loaded, all Items were
set to RefCount 5000, the references from the objects were restored
and then for each Item the RefCount was lowered by 5000 again
and - if being zero - deleted. Items for UI were marked 'non-poolable'
to *not* safe them with the document, so poolable was a flag to decide
if that Info/Item was to be saved with the document - or more direct:
if it is Model Data.
Items are small, so if we prefer runtime it is okay to no longer being
strict with this, anyways does not happen often and has only marginal
memory effects - compared to runtime effects/savings.
Other problems which this caused: One example is that objects in the
UNDO stack were still in the pool, so e.g. deleted pictures were saved
with the document despite no longer being used (!). That is the reason
we have an UndoItemPool and a method MigrateItemPool to move stuff to
that Pool when objects go to the UNDO stack - all of this is also no
longer needed.
Cleaning this up means to ideally have 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>
|
|
The document had overlapping text on load since commit
05425f73bfa41d3f7591461e2ad0beb4fafc39b4 (sw floatable: teach the RTF
import about SwFormatFlySplit, 2023-04-21).
Interestingly the DOCX equivalent was fine, there the inline table is
shifted down, below the floating table, so the overlap doesn't happen.
Fix the problem by moving the AddVerticalFrameOffsets=true code from the
DOCX filter to the shared dmapper, because RTF needs the same.
See commit 50223ea6e212b60b7d33839c2753c5601fb50f95 (tdf#98987 sw: add
AddVerticalFrameOffsets compat mode, 2016-03-31) for more details about
this compat flag. It was already enabled for DOC, too.
Change-Id: I948b179c9ec5fa24377014b0e86826568c417b6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158372
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ifcb57548a594cbbaf70df8d9da17cf94a96667db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158146
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If054626a10d3cbd3b168dd4e66ec7f08344d2c2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158131
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Previously, ChartViewHelper::setViewToDirtyState was only called in
ChartModel::impl_notifyModifiedListeners during the load process of
inline charts; after commit 574eec9036c5f185b3572ba1e0ca9d111eb361dc,
the chart doesn't set its modified state when loading, and thus the
view did not get notified about the necessary updates.
This change introduces a hidden property in ChartDocumentWrapper,
named 'ODFImport_UpdateView', which is set in SchXMLImport dtor
to force the notification after the loading.
Change-Id: Id9d82f16d233d2172cd6808a8498822e13b21b21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158051
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
When the chart is painted for the first time, its update may create
the initial set of objects, which used to set modified state after
loading documents.
Change-Id: Ie50ef34875440058020486192fe649b492e4baf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158015
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4948cc217079d2ed535b95e3892e619736237cc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158014
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: Ica10c62066881ba86099d2057ff6fe20e0084a85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157632
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
with soffice --headless --convert-to ods forum-mso-en4-569016.xlsx
and other similar
Change-Id: I908fa834c1072a9854055cad1ee6261800d76aea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157573
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
...after 6ef2d358ac053ce0f6de9cf0f8f25e8bae66d441 "Adapt Clang and GCC minimum
version checks"
Change-Id: I5f3bcda2ce8e0e093af3bdd9d2cca741a5b95306
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157202
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I15df992e410f741a22d1f140b85e57a97195a5f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157020
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
has always been ignored
Change-Id: I272ca7026ddf25fbc679e7933ea23986466ad70b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156822
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
directly set content area container to avoid
buttons on top of the dialog in lok case
Change-Id: I8353102f679a8f19c3041c7b4ec0b1200ed7d515
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156254
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Pranam Lashkari <lpranam@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156813
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: Ifb793b9f1d1476617239b826705f8838bdc66303
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156714
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
regression from
commit bdf2d664784b3ebe3e7078b9ec82a02d09d9ded8
Author: Noel Grandin <noelgrandin@gmail.com>
Date: Sat Sep 2 10:44:51 2023 +0200
use more concrete type in AccessibleChartView
Change-Id: I5f76f10404d6a202b1653f5e7cabc665b5962557
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156615
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3ad20c37bb2009964cf20a1ee184b2674de82817
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156470
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
not the implementation, just the registering as a component - there
is no way to instantiate and use this object as a real service, it
is intimately tied into the chart2 internals.
Change-Id: I5c80e23f2b043bef23650664a7cc2c7813248433
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156471
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1ec6c7bdd0f7ab487ba1ade89cd545f5bc97f540
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156466
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's a little easier to read, but mostly it makes an upcoming
loplugin easier to implement
Change-Id: I4ae7db8eda77795dab3255d1afd8ba4f20a8de76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156451
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... from commit a3acf41195f4c39cba7950c389dc817b824f76ed (CWS-TOOLING:
integrate CWS chart37, 2009-06-04)
Change-Id: I32b3813ff0d76fc1dffd98080ce894781f3028cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155893
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This is needed because the module dependencies are an issues if
the conversion is done in basegfx. The bigger issue will come when
the ComplexColor conversion will be done as basegfx can't depend on
docmodel because of circular dependencies.
The BGradient is also more suitable for docmodel anyway as the
previously it was part of the model and is not a basic (gfx)
type - however this doesn't move the whole BGradient into docmodel
yet.
Change-Id: Id91ce52232f89f00e09b451c13da36e2854ae14b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155674
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
on loading sw//qa/extras/layout/data/tdf125334.odt and double clicking
chart
Change-Id: I65b10c0223e9c217d77dc7daa73580fadffc32c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155096
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
rather than having to override 3 different methods, have them override
the ImplInvalidate, which is where the code ends up anywhere.
This already exposes a couple of places that were not overriding all 3
methods.
Change-Id: If76abcf18325b7138ea451fbd0213cd6c7b4daa5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154930
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When opening a file containing a Moving average trend line,
addRegressionCurve is not used, then MayHaveCorrelationCoefficient property is not
correctly set.
This change modify this property in all cases.
Update property in firePropertyChangeEvent() as it is not possible in
constructor: JunitTest_chart2_unoapi fails in MeanValue as SolarMutex
is not owned
Add QA test
Change-Id: I13bdb81239a7362431edcf28bfc38ac4820a7776
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153859
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0a3afe10dec530a6d7ddc32cf7d96ec5095604c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154431
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I276ba7809b08a359b377ea56259140675c5e00a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* SdrObject new member m_IsDecorative
* new Undo SdrUndoObjDecorative
* surprising amount of changes in sw including additional SwUndoFlyDecorative
* svx API SvxShape property "Decorative"
* UI checkbox "Decorative"
* ODF import/export as loext:decorative on style:graphic-properties
* PDF/UA export: ViewObjectContcat tag shapes with this flag as Artifact
Change-Id: I37f7a0597eab92c6c6aff94fad6c16c59b231c80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154063
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
merging two different enums in the process
Change-Id: I81ff8f10158a19a1b3a4ffe35fac6653beb677ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154028
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ieb61797fa230d4b7d7650cfcb8b7c988bf292189
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153822
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
Previous commit dc03f59374d4fc74dd44ddedc903bb9c00a74bb7 broke text in
status bar when a moving average trend line is selected
Change-Id: I259fb9aee1eccf9fac93038c6dd2755490769f88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153677
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Moving average trend line does not R² value.
This change remove "Insert R²" from context menu when the trend is of
type "Moving average"
Change-Id: I729a6421df34859e7176c798a2b68a6f13cfb544
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153294
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Insert Period value earlier to have it ready for representation
Allow Moving average equation in dialog UI
Change-Id: I1d20572c39462e60b60ab7eec1f174a3cf934d4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153094
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
a speculative fix for:
https://crashreport.libreoffice.org/stats/crash_details/5b3c8597-9ffa-49b8-8cc2-132e69456249
Change-Id: I4f45cf4c7ed51c814d4cb01b8f55709586d7a981
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152745
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
|
|
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>
|
|
This reverts commit 5e68d6cfade45f40b1ad46025a81afe4cb8dd337.
Reason for revert: Seems like outside users have been using this API
Change-Id: I8814cf1eb4f000eeb4cbbb5db9c282d001465993
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152441
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There is no need for it to be an UNO interface anymore (ever since
we started supporting dynamic_cast on UNO objects).
Which means that XImportFilter2 also needs become a C++ interface.
Change-Id: Ice2db0f098271bba32b199bd083b08cb8410ce93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152388
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There is no need to do this, as the documentation of
css.lang.XComponent::dispose at
udkapi/com/sun/star/lang/XComponent.idl
states:
After this method has been called, the object should
behave as passive as possible, thus it should ignore all calls
Otherwise, the effect of throwing here is mostly to disturb the flow of
logic in caller code, preventing other parts of teardown from proceeding
smoothly.
Change-Id: I30e6d1b35f85b727debf4405a995fdc0a4fccde6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152450
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
found with a lightly tweaked version of the loplugin:stringadd
and some hand-holding.
Change-Id: I146aadcaf665e98fea89a9cad2df4dc3935622f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152275
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9a9656ddce9c12564411cfcb3e8e8714ae74a418
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152236
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ice1625e8cae8da859ea8a940b3f8e40f6f9d7037
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152235
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This reverts 7.1 commit 6a915073f8400fd34274cf311994bbc9bf498ab6.
The change was simply wrong. There is NOTHING about this context
that indicates that a double-click is happening.
So whatever this patch was trying to do,
it simply was made in a completely wrong way.
So best to just revert, and put the onus back on the interested
parties to redesign a fix for their double-click issue.
Change-Id: Ia209c0552839d6cce1b348432789f0f861ac5703
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152023
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
|
|
since we know that this is a matrix only used for 2D transforms,
we know that the last row of the matrix is always { 0, 0, 1 }.
Therefore, we don't need to store that information, and
we can simplify some of the computations.
Also remove operations like operator+ which are not legal for
such a matrix.
Change-Id: I482de9a45ebbedf79e3b6033575aab590e61c2d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151909
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
