using == to compare them doesnt work, because we return
a new one with every call to getTopFocusWindow and similar.
So add a equals() method to the UNO interface to do the comparison.
Change-Id: Ie909fe9b4e84fe07f4ca87bbebf65b56d3da8f78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165436
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
Implement ODF import/export for bar-of-pie and pie-of-pie types,
and add simple tests for this capability. The associated ODF tags
are implemented in the loext namespace. This also required changing
the schema.
Change-Id: Ib55ae1c5818ad810f7b962d807a9163a3d02ba17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164436
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
duplicating sheet or when saving a file and reopen it.
When creating a title for an axis, "createTitle" is called.
Before tdf#92768 "support hiding title objects", when unchecking "axis title" in sidebar,
the title was removed (via "removeTitle")
But since tdf#92768, "hideTitle" is called instead.
The pb is "Visible" attribute wasn't registered in StaticTitleWrapperPropertyArray.
So when duplicating sheet after having created a title and hidden it,
when duplicating sheet, the new sheet had the title visible.
In the same way if, after having created a title and hidden it,
you save the file and reopen it, the title is displayed.
Change-Id: I980505ec02906e673dd60a60e4d9837928bf8876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164938
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
lcl_AllOperator is used in XChartDocument::attachData implementation.
When a data without existing categories is passed there, like an XY
scatter, lcl_AllOperator used to force creation of the categories in
the target, by returning 'true' unconditionally from setsCategories.
This meant, that a new sequence of numbers starting from 1 was used
as X values, and the old X data was interpreted as an extra Y series.
This changes lcl_AllOperator::setsCategories to try to check if its
data actually contains categories. Thus, XChartDocument::attachData
will use categories either when the chart already uses categories,
and ChartDataWrapper::applyData detects that using a call to
DataSourceHelper::detectRangeSegmentation; or when the new data has
it; but not when neither had it. When it's not possible to detect if
there were categories in the new data (e.g., with user data), old
behavior is used, setting categories.
It could be an alternative to detect the chart type using
xOldDoc->getDiagram()->getDiagramType() == "com.sun.star.chart.XYDiagram"
in XChartDocument::attachData; and then decide to force the creation
or not. But it seems hackish, and not really universal: other chart
types must be tested (bubble?), no idea how to handle hypothetical
cases when applied data contains categories in case of XY chart, etc.
Change-Id: I86b34f6799c30b103f7fc6b2faf6ec255a9d137b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164298
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
Updated the chart properties dialogs to work asynchronously. The changes affect the following dialogs:
Chart Type: Accessible by double-clicking on a chart to select it, then right-clicking to open the context menu. Selecting 'Chart type...' opens the dialog for modifying chart types.
Insert Axes: Triggered by double-clicking on a chart to select it, then right-clicking and choosing 'Insert/Delete Axes' from the context menu. This dialog allows users to add or remove chart axes.
Insert Titles: Opens when you double-click on a chart, right-click, and select 'Insert Titles...' from the context menu. It's used for adding titles to the chart and its axes.
Insert Trendline: For column charts, you can double-click on a column, right-click, and choose 'Insert trendline..' to open this dialog.
Insert Error Bars: In a column chart, after selecting a column, right-clicking and choosing 'Insert X Error Bars..' or 'Insert Y Error Bars..' opens the dialog for adding error bars to the chart.
Signed-off-by: codewithvk <vivek.javiya@collabora.com>
Change-Id: Id7bb8682150f2e3115420d9259c6afd41682641e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162655
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 71a3cfb71dddba8098d74d7bb1dd414e4696914b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162824
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
... and use a compatible 1/5 width if not specified.
This patch depends on the previous oox patch
(commit 301e27cbeb)
which actually reads the width into the model.
Fixes a 7.2 regression from
commit b006834239
author Tünde Tóth on Wed Dec 16 18:26:26 2020 +0100
tdf#138777 pie chart: improve long data label width
and is basically a re-write of 7.1's
commit 20da1a5dd3
author Tünde Tóth <toth.tunde@nisz.hu> on Fri Oct 09 09:24:18 2020 +0200
tdf#134978 Chart OOXML Import: fix pie chart label custom position
This is very risky, but then ANYTHING changing chart2 is risky.
There were a lot of changes made in 7.1,
and they all invited regressions.
However, our chart implementation is not in a good state,
and certainly is not very interoperable,
so it is worth taking the risk.
Anything dealing with manualLayout at this point
should have originated as a pptx,
so forcing a compatible max width should be fairly safe.
It probably isn't actually all that risky after all.
largely copied code from
commit 4223ff2be6
Author: Balazs Varga on Wed Jan 15 16:31:35 2020 +0100
tdf#48436 Chart: add CustomLabelPosition UNO API property
Fortunately this all goes away after a round-trip
since custom label placement is lost on export to OOXML,
and that really helps to reduce the risk.
make CppunitTest_chart2_import CPPUNIT_TEST_NAME=testTdf146487
Change-Id: I9722fc6c759c15ac3924780e6fc124f02fba07e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162590
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Sorted out some methods at ItemPool which process
Defaults to make more clear what is going on and
what which method is doing.
Change-Id: I2568d3e03d0a56a14b6fe4e04521e1a8e22c000b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162643
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Insert a chart, user #1 select it, user #2 select it. User #1 double click
it, double click again the legend to get dialog to edit it. User #2 delete
chart, User #1 'ok'
#0 0x00007f5365797d59 in osl::Mutex::acquire (this=<optimized out>) at include/osl/mutex.hxx:63
#1 osl::ClearableGuard<osl::Mutex>::ClearableGuard (t=..., this=0x7ffc7ffcccf0) at include/osl/mutex.hxx:182
#2 apphelper::LifeTimeGuard::LifeTimeGuard (rManager=..., this=0x7ffc7ffcccf0) at chart2/source/inc/LifeTime.hxx:175
#3 chart::ChartModel::lockControllers (this=0x0) at chart2/source/model/main/ChartModel.cxx:415
#4 0x00007f53658375ab in chart::ControllerLockGuardUNO::ControllerLockGuardUNO (this=this@entry=0x7ffc7ffcce80, xModel=...)
at chart2/source/tools/ControllerLockGuard.cxx:34
#5 0x00007f5364df5f34 in chart::ChartController::executeDlg_ObjectProperties_withoutUndoGuard (this=<optimized out>, rObjectCID=..., bSuccessOnUnchanged=<optimized out>)
at chart2/source/controller/main/ChartController_Properties.cxx:797
#6 0x00007f5364df7a5e in chart::ChartController::executeDlg_ObjectProperties (this=0x7f535401f310, rSelectedObjectCID=...)
at chart2/source/controller/main/ChartController_Properties.cxx:707
#7 0x00007f5364e0f497 in chart::ChartController::execute_MouseButtonUp (this=<optimized out>, rMEvt=...) at chart2/source/controller/main/ChartController_Window.cxx:924
#8 0x00007f53760d61dc in (anonymous namespace)::LOKPostAsyncEvent (pEv=0x55e2f1b93db0) at sfx2/source/view/lokhelper.cxx:893
#9 0x00007f53760d0977 in LokChartHelper::postMouseEvent (this=<optimized out>, nType=1, nX=<optimized out>, nY=<optimized out>, nCount=2, nButtons=1, nModifier=0, fScaleX=0.083333333333333329,
fScaleY=0.083333333333333329) at sfx2/source/view/lokcharthelper.cxx:294
just hold a reference to the chart the dialog operates on
Change-Id: I3b05d1fc12e4df899c1a996f1029f9d3d62e87ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161099
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
...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>
Previously, ChartViewHelper::setViewToDirtyState was only called in
ChartModel::impl_notifyModifiedListeners during the load process of
inline charts; after commit 574eec9036,
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>
Noel Grandin