Both are derived from SfxSetItem which means they contain
a SfxItemSet themselves. That leads to problems since at
their construction time a SfxItemPool has to be known and
it *should* not be different to the one of the ItemSet
that Item gets added later - that leads to the 2nd class
of problems.
In the long therm we should get rid of all SfxSetItems.
This change simplifies already some stuff, including that
the standard Items for DrawObjects reduces by two (and
more due to containing a whole ItemSet) and e.g. the
problem that these Items had to be converted to hard
attributes in the done fixes for copy/pasting Slides.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I8b1c6cabdaa43ed6062811b5508ab3dece47a755
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6795
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e67458a9b769fe7a3a7ee0739ed6d5c46dbc0692)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211734
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
As Eike indicated in https://bugs.documentfoundation.org/show_bug.cgi?id=146404#c4
COLOR format codes are preserved in ods/fods format.
The pb was the missing map back.
Indeed, we had the mapping for [COLOR<something>] => Color value (eg: "ffaa16")
but not the reverse mapping Color value => [COLOR<something>]
Eike had provided the right code pointer in xmlnumfi.cxx.
First, I thought using PaletteManager but this one is in svx and svx shouldn't be used in xmloff
(dependency pb).
Then I used ChatGpt (GPT-5.6 Luna) and it pointed the right process.
It just consisted to use a similar callback system (DECL_LINK, IMPL_LINK, LINK) of GetUserDefinedColor.
In addition, by testing all this, I noticed that maList in XColorList::GetIndexOfColor was empty.
So I added the Load call in case mbListDirty is true.
Change-Id: I0ef6b5901f2e4c757e88994412dbf79a13100ffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210518
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Introduce an SfxPoolItem in the SDR graphic attribute range that
carries a basegfx::B2DPolyPolygon clip outline on SdrGrafObj.
Allocate SDRATTR_GRAFCLIPPOLYPOLYGON between SDRATTR_GRAFCROP and
SDRATTR_GRAF_LAST (which shifts SDRATTR_3D_FIRST and the downstream
ids by one), register the pool default, and surface the value as the
"GraphicClipPolyPolygon" UNO property on the GraphicObjectShape
property map (covering both drawing.GraphicObjectShape and
presentation.GraphicObjectShape via SVXMAP_GRAPHICOBJECT) using the
css::drawing::PolyPolygonBezierCoords type. QueryValue/PutValue
do the round-trip through the existing basegfx helpers.
The new which-id is 1175. The trailing comments in svddef.hxx have
run 2 high since two XATTR items were dropped upstream, so the ones
added here say 1177 to stay consistent with the file.
No reader, writer or render path consumes the property yet; this
is infrastructure for upcoming custGeom round-trip work on empty
picture placeholders.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I17d98cabeb230c25b3de0da4eadd8338ed672ce1
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9190
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit be7f21fc7187bb87129eed4e8ed2f794faf6e757)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210036
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
In commit 93aa742ba3 which is
20 years ago 'cl' did a big change to get to SfxUndoManager
which is a needed abstraction for the formally Svx-based
Undo/Redo stuff.
Unfortunately SdrModel::SetUndoComment was *not* supported
and this was expressed as just doing a
OSL_FAIL("svx::SdrModel::SetUndoComment(), method not supported with application undo manager!" );
in SdrModel::SetUndoComment when SfxUndoManager was used.
But SetUndoComment *is* used in nine cases in
svdraw/svdedtv2.cxx. All of these execute some action and
create Undos for it. All nine Undos were without any Undo
text since then - over 20 years...
I stumbled over that when adding needed Diagram stuff to
UnGroupMarked().
I fix this with this commit. Creating that fix showed me
why 'cl' intentionally did not support that, but just
abandoning functionality is not a good choice.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Idde2fcecc85a9eee39b62d38ed7d71a8cfbd3288
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2486
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 5adf090261d705123074a0fa1c46119b2bf44bf3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206022
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
When rows, columns, or sheets are deleted, referencing cells can
result in #REF! errors without warning. Manual reconstruction is
often time-intensive once the session is closed, so this patch
detects these errors and shows a warning infobar to alert the user.
The infobar includes a "Go to First Error" button that navigates to
the first affected formula cell. Only the first error is surfaced to
avoid UI clutter. The warning is dismissed on undo and re-shown on
redo automatically.
The feature is controlled by an Expert Configuration option at
org.openoffice.Office.Calc/Input/WarnOnDeleteCellReferences
(default: off for now).
See: https://github.com/CollaboraOnline/online/issues/2861
Change-Id: I649296444e783c88cbd4688109ac10b3a1bb5046
Signed-off-by: Ferdinand Gassauer <f.gassauer@chricar.at>
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/816
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
(cherry picked from commit b3354e376bee90dedf1fe84b5cf6f4f3c17b7f70)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205499
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
Add LockFileCommon::FormatDateTime() to parse the fixed-format lock
file time string (DD.MM.YYYY HH:MM) and reformat it using the user's
configured locale setting
Add unit tests for LockFileCommon::FormatDateTime()
- testFormatDateTimeShortInput()
- testFormatDateTimeLocaleOutput()
Change-Id: I77c94dc2a21d9bec6cf5e2584556cd89f216c40d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204683
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
The Organizer tab of the style dialog now shows interactive "chips"
for each property that differs from the parent style. Each chip
displays the property name and value, and includes an X button to
reset that property back to parent inheritance. All properties
are shown full text, no ellipsis.
Properties are grouped by tab page (Font, Font effects, etc.)
and displayed in a scrollable area. A View/Edit toggle lets the
user switch between the traditional description text and the
interactive chip view.
Implementation summary:
- New PropertyChip and PropertyCategoryRow widgets (sfx2) with
corresponding .ui files for the chip layout.
- SfxStyleSheetBase::GetItemPresentation() virtual method returns
per-property presentation strings, overridden in SwDocStyleSheet
and ScStyleSheet for module-specific attributes.
- SfxItemSet access tracker mechanism to automatically map WhichIds
to their owning tab pages via BuildWhichToTabMap().
- SfxTabDialogController::InvalidateItem() propagates chip resets
to the output set and affected tab pages.
- SwDocStyleSheet::ResetItems() uses SwDoc::ResetAttrAtFormat() to
ensure proper undo support in Writer.
- SfxStyleDialogController::Ok() clears invalidated items from the
style's item set on dialog confirmation.
- SvxAsianTabPage now calls SetExchangeSupport() and implements
DeactivatePage() so its items are properly tracked.
- Access tracker ignore guards in SvxCharBasePage::SetPrevFontWidthScale
and SvxTransparenceTabPage::InitPreview to avoid false positives
from preview-only item access.
Includes a UITest for Writer (sw/qa/uitest/ui/fmtui/tdf89826.py)
that creates a child style, modifies a property, removes it via
chip, and verifies inheritance is restored including undo.
A Calc UITest is not included because the style edit dialog in Calc
is opened asynchronously (ScTabViewShell::ExecuteStyleEdit) and the
UITest framework's execute_dialog_through_command cannot capture it.
The Calc functionality has been verified manually. A Calc UITest can
be added once the framework supports async style dialogs.
Change-Id: Ia764405798c212fe5340bba254f2ff6ac62365f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199318
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
- qFormat - specifies if style should be shown in more prominent places
in the UI even if unused
- we show it in that case not only in all styles in sidebar, but also
in the notebookbar style previews
- this is Writer specific, implemented on sw/ style iterator and SwFormat
level
- XStyles is interface common for all modules but in fact we do per module
implementations it seems and there is no sense to propagate that value
everywhere
- currently we have also qFormat export so just reuse grab bag value
Change-Id: Iee8f35a3e575c3c1caf6c67f8b489d7d64932cf5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193398
(cherry picked from commit cee5c21e0c8c64c78e5d04ff4e300edfaac30404)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194550
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
These defaults don't provide any advantages over the base overload,
which works just fine in case when there's no ppItem argument. The
ppItem argument is the only sensible reason to use the templatized
overload.
Change-Id: Ic17fe1da7a3c02f9e7ebbe725060fcf129bc9f24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194616
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It feels safer in CloneSetWhich; previously, there was no way to make
sure that the passed TypedWhichId makes sense.
Change-Id: I1df520282f5407a69a095d959d107f6b78621f75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194422
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
similar to what we do for viewID.
On attemting to load multiple documents StatusIndicator::start calls
Application::Reschedule during load of document #1.
That inner loop ends up loading document #2. The inner loop ends, and
load of document #1 completes in the outer loop.
Unfortunately the inner loop left the current DocumentId as that of the
inner document #2, so the document id set on the view of #1 is
incorrect.
Extend the similar fix for viewId switching during Reschedule to restore
the docId. If this Reschedule happens at any other time except load then
restoring the viewId is sufficient to identify the correct document, but
in the load case there is no viewId yet
Move the mnCurrentDocId out of sfx2 and ViewShell into comphelper so
it's available from vcl without needing to make any adjustments to
LibreOfficeKit.h[xx]
Change-Id: Ied70e0f9ff33f2587cfbcb02b0c9ca3cd4792cfd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193814
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Implements the ODF 1.2 paragraph attribute style:writing-mode-automatic,
and supporting runtime features. When set, this attribute allows
programs to automatically recompute the paragraph writing mode when the
contents of the paragraph have been edited.
The ODF standard does not suggest any particular algorithm for
automatically determining paragraph direction. This implementation uses
the rules from Unicode UAX #9 3.3.1.
Currently, LO will only automatically change the writing direction when
new text is typed or deleted. Other known interesting cases are already
tracked as separate enhancement requests.
Change-Id: I49eecea36952588dc98f2a98ebce712cd2846c0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193547
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
It seems that some DDE code was virtually never tested in our CI.
That resulted in several unnoticed regressions.
In commit 81b954718f
(loplugin:unnecessaryvirtuals, 2015-06-09), DdeService::MakeTopic
was made non-virtual. That broke its use on Windows, where a derived
class used to override that method (which of course didn't use the
'override' keyvord, hence went unnoticed).
In commit 88e3b846b8 (remove some dead
bits of DDE, 2016-04-06), DdeService::MakeTopic was finally dropped.
In commit c026b93640 (no need to
allocate SfxDdeDocTopics_Impl separately, 2023-02-28), a check in
SfxApplication::AddDdeTopic was changed from testing if pDocTopics
were initialized to checking if they are empty. The new test made
adding anything to the vector impossible.
This change tried to make it functional again, and adds a (Windows-
only) unit test.
To enable unit test, we need an app name, so that DDE is initialized
properly. Also, ImplDdeService::MakeTopic had a condition to exit
early, when !Application::IsInExecute(). Here we allow to add it, if
unit test is running.
SfxDdeDocTopic_Impl::Put ismodified to store OUString to the Any -
see ScByteSequenceToString::GetString. Without the change, UTF-16
was treated as 8-bit-encoded string.
theDdeInstData in svl/source/svdde/ddecli.cxx is now not a pointer,
bus a function-local static. No need to delete it: it has nothing
that needs to be released. Before, it could get destroyed too early,
preventing DDE from working.
DdeConnection::~DdeConnection could reliably deadlock, when it had
a connection to the server in the same process; processEventsToIdle
is called now to avoid that.
DdeData ctor taking OUString is fixed: xImp->nData is bytes, not
characters.
Change-Id: I9a151eebc65a26b76c9f6134e97cd1f4d2e2b615
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192640
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
editeng paragraphs can refer to styles, but what are those styles,
stored in SdrModel was not visible previously.
Change-Id: Ic32795341595a4d8b61c8c686cd0b140034c1a7f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192163
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Armin Le Grand (collabora)