In the past, weld.hxx used to contain the class
definitions for weld::Widget and all subclasses.
By now, weld::Widget and almost all subclasses have
been moved to separate headers, to make it easier
to keep the overview and to avoid having to
recompile ~all UI code when one class changes.
By now, only weld::Button is left in weld.hxx.
Rename the header to Button.hxx.
Drop weld.hxx includes and instead add Button.hxx
includes (or weld::Button forward declarations) where
weld::Button is used.
(Don't simply replace all weld.hxx includes with
Button.hxx ones, since many of them were for the
use of other widgets that have since been moved
to their own headers.)
Add further includes where needed now that the
(direct or transitive) includes of weld.hxx were removed.
Change-Id: I8ea6201446a418d5e38b46337059dcd517ee29d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205937
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The autocorrect functions take as arguments an abstract interface to a
document and a string reference containing the text for the paragraph
being updated. The string needs to be a reference to the actual text
used for the document because the functions rely on it being
automatically updated when modifications are made to the paragraph. This
causes problems when redlines are enabled and the text comes from a
MergedPara because some operations can cause the MergedPara to be
recreated. The SvxAutoCorrect::DoAutoCorrect function has many
workarounds to try and fix this problem. The one from the commit below
tries to fix it for the case where a small group of autocorrect
functions can all be run together by making a temporary copy of the
string. This isn’t ideal because the different functions can no longer
see the result of the other functions. This is particularly bad for the
Esperanto hat function that was added after the patch was created. For
example “cxu” at the start of a sentence will be corrected to “Cu”
instead of “Ĉu” beause the word capitaliser can’t see the result of the
esperanto hat function adding the hat so it only capitalises the letter
“c”.
To fix this this patch adds a method to SvxAutoCorrDoc to get the latest
version of the paragraph text. That way each function can query the
string at the start and it won’t matter if it comes from a recreated
MergedPara. Ideally I think we should eventually move all autocorrect
functions to use this method and then remove the rTxt parameter to make
the code a bit more robust.
commit 22baeb9f9e
Author: Andras Timar <andras.timar@collabora.com>
Date: Thu Mar 19 10:19:21 2026 +0100
sw autocorrect: fix use-after-free with track changes enabled
Change-Id: Id407be018bdfa31c6f4642a9503c65e4c9e736d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205235
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
This is in preparation of moving code out of weld.hxx
to separate headers/source files, in order to make it
easier to keep an overview and to avoid having to
recompile ~all UI code when anything changes.
Also move weldutils.cxx to a new vcl/source/weld
directory.
Change-Id: Ia75b42f21e560dd248307282a522f186a64cd742
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195777
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Since 6c8b802051 which is
'StripPortions: full Primitive usage for EditEngine Paint'
all DrawText_To* methods were already using a full
conversion to Primitives which then get painted directly,
see commit comment there.
Since then no complaints/errors came up I now continue
to move EditEngine to Primitive usage. Lots of code for
the still also existing DirectPaint gets removed.
I also drive forward changes to have less parameters
for the ImpEditEngine::StripAllPortions method. It is
already cleared by the former possible rotation, this
can (and is) replaced by embedding the result to a
transform primitive doing that rotation. I changed
two of three using methods to strip always to
position (0, 0) which can also be unified to embedding
to a transformation. The third one will need some more
work here due to doing wild things in Outliner mode in
Impress (callbacks & creating Primitives in fixed
positions for which an embedding translate would be
wrong).
When being able to strip without position and rotation
the result will be usable to be buffered, so the goal
is to re-use that, transformed as needed (translate,
scale, rotate, ...) as long as the text itself does
not change.
Change-Id: I52ab548ccbb1b5b3b16c50451a314bc7f3b39d93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188918
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
and just have a single pool for the EditEngine machinery.
I cannot find a reason for a separat pool anymore, probably
it was a thing from the distant past.
This also shaves 5% off the load time of tdf#162126 because
we no longer have to spend losts of time re-creating SfxItemSets
because they belong to different pools.
Change-Id: I837045809dc292548b10e2cf5173d2a29b0879a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187969
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Moved central stuff needed for decompose to Primitives
closer to EditEngine/Outliner. There is now a
StripPortionsHelper as abstract base class with two virtual
methods replacing the lambdas used before. That is easily
implementable to all needs. Adapted all usages. Also the
methods for creating needed Primitives from DrawPortionInfo
or DrawBulletInfo is now local/private in EditEngine.
This step should still change nothing in functionality, but
is more preparation to be able to directly create Primitives
from Outliner/EditEngine setups for paint and (re)use.
Change-Id: Ie2bcebf4030128f88be229d789944cc2842eafb6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187045
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Implemented the ODF 1.0 style:script-type text property. This property
can be used by documents to influence which script type-dependent
attributes are used when rendering certain characters.
This implementation uses the following semantics:
- If unset, the behavior is as it was in previous versions.
- If set to latin, asian, or complex, those characters not mapped by the
ODF standard to a script type are treated as latin, asian, or complex,
respectively.
- If set to ignore, all characters will be treated as latin. This value
is intended to be used for interoperability with file formats that
don't implement script types (e.g. HTML).
Change-Id: If81a1390ee455fd971dea655d161d9c3f44fd08a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186309
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Implements a minimal functional version of ruby character layout and
rendering in Edit Engine. Many features are missing from this
implementation, and will be added in future commits.
Currently, ruby characters cannot be created via the user interface.
Ruby character styles are also currently hard-coded.
Change-Id: Ia7c18ccae6c37cd320acc214574ba3123c18ddb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185210
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
Add a config header for this, and split yrs.hxx in two because the
actual libyrs.h is only needed in 2 files.
Change-Id: I30453fda3082f977e328ed56a4a101743ecdd586
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185329
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The cursors are represented as integers in yrs as a first step, which
isn't ideal.
Surprisingly EditView doesn't really have functions to correct the
cursor, only ImpEditEngine::UpdateSelections() for the case when nodes
are deleted, apparently there's only one active EditView at a time
typically so it wasn't needed? Typically the active EditView's cursor
is assigned from a return value of ImpEditEngine.
Add some new functions to correct peer cursors and call them all over
ImpEditEngine; unfortunately UpdateSelectionsDelete() isn't easy to get
working on EditView's actual EditSelection cursor so leave that for the
future...
To fix EE paint of non-active comment, add SwAnnotationWin::Paint()
To get things to paint with "gen", it's enough to invalidate the
SwAnnotationWin, but for gtk3 a queue_draw() must be called, else it's
only painted when clicking on the window.
Cursors are painted in color in SidebarTextControl::Paint()
Change-Id: Id8696238290405554ece1b9961676972a559b58e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181679
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This can be enabled in configure via --with-yrs=...; see also README.yrs
Currently this is hardcoded to run over a local named pipe.
Everything related to editengine is implemented in EditDoc and made
accessible via its wrapper classes; everything related to communication
and accessing sw's comment is implemented in sw::DocumentStateManager.
The acceptor starts in SwView::SwView(), once SwPostItMgr exists.
There is a hack in SfxFrameLoader_Impl::load() to fetch the document
that the accepting soffice has loaded, and load it in the connecting
soffice as well.
Change-Id: I89476b5864b70f479bcf15989374c1c65b5da9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175652
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
When checking how TextEdit on the Overlay may be doable in Calc
I stumbled about that I initially did that based on Outliner
(svx) for all DrawObjects/Draw/Impress, but it is not accessible
from EditEngine.
Calc again just uses an EditEngine for TextEdit in Cell, so I
checked doability. Quite some stuff has to be changed, basically
instead of unsing IMPL/DECL_LINK I use lambda functions now. The
former callbacks were anyways exclusively used for this and had
no general used case.
Also simplified and cleaned up quite some other stuff, some
member functions could be removed, some helper classes deleted
or simplified/streamlined.
This should do no change to existing decomposes or edit views,
but will make it possible to move in the direction of CellEdit
on the Overlay and also prepares decompositions there to allow
going in the direction of primitive based paints in Calc.
Change-Id: Ia9c4c1129c9579ba4870b091977082e5f0d319f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183388
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
This is the continuation of the cleanup of class SfxItemSetFixed.
This patch contains a few edge cases, more specifically when SfxItemSetFixed is used in header files.
Change-Id: I2ed48177ca53311b20b9e2a8aed95d3b1c87f250
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180309
Tested-by: Jenkins
Reviewed-by: Rafael Lima <rafael.palma.lima@gmail.com>
Some optimization in commit 52abeff6d5836b29dbefe69f284bbd89f6672ae2
ignores paragph attributes if the paragraph is empty.
But it is not empty if it has an active list.
Change-Id: I8885d0f201fc48279263a3d41ec6d660b534ded2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178311
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
which allows us to eliminate a bunch of rounding at various layers, and
consequently maintain a lot more precision
Change-Id: I911dedd7c041c1d67396c082e5695346ea689acb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175814
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The EditEngine decomposes it's content mainly to
Prmitives (there is still a direct paint mode used
in rare remaining cases which we not yet got rid
of). For TABs the special case for 'extended' TABs
(see format/paragraph/Tabs, FillCharacter) was
handed through all layers using method DrawingTab,
put into a DrawPortionInfo and held at the text
primitive (TextSimplePortionPrimitive2D). While
for direct paint the expansion was already done in
ImpEditEngine::Paint anyways (and always painted,
independent from bStripOnly what was unneccessary
and I corrected that, too) it had to be done for
text paint in VclProcessor2D for each repaint.
This is not needed, so now the extended text
created in EditEngine decompose gets used.
This makes a lot of stuff simpler, including
EditEngine/Outliner and some involved classes.
If it somehow should show that it might be
necessary to do that for each paint it should
be done in the obvious way then - using an own
primitive that creates the expansin in the
decomposition (and buffers it).
Change-Id: Ieb02219142af8f6bee01dcd658e08b185a4212cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171380
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Modified ImpEditEngine::CreateLines and ImpEditEngine::Paint
to wrap multiline fields (hyperlinks) to wrap better:
Multiline hyperlinks can start/end in the middle of a line.
like this:
text hyperlink-start
hyperlink-line2.....
hyperlink-end text
Start of the lines of the multiline hyperlinks now follow the line
start (for example if the 1. line has a bullet/indent, and the
2. line does not then the multiline hyperlink 2. line will start
where normal 2. line would start)
Changed the way how fields wrapped while editing.. (we didn't split
fields into lines, when its textbox is edited, but now we do)
This way it is more a WYSIWYG editor. (when we edit, we see what
we will get)
Changed the constant reference rLine to non-constant pointer
pLine, because this hack change the actual line to the next line
at the end of a muliline hyperlink, so the algotithm will
continue calculating with the next line, as if it would be still
the previous line.
Change-Id: I2c67f4ae1b86ee9c73f01ae0c045f02e56a09c1c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162503
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@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>
Change operator[] for getRef(..) method, so instead of returning
a pointer, return a reference to ParaPortion instead. This also
needs changes to the code, because we now need to make sure before
hand that the ParaPortion is really available in the list and when
this is not possible or convenient, the change the call to use
existing "SafeGetObject" instead. Add "exists" to check if the
object is available in the ParaPortionList.
In addition add "lastIndex" method to return the index of the
last ParaPortion in the list (shortcut for Count() - 1).
Change-Id: Id52c38f996468af51c75d50185110ec8502169e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162071
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Don't use raw pointers, when it is possible to move the unique_ptr
around into another object that is responsible for the object's
ownership.
The ContentNode is either in a vector in the EditDoc class or it
is moved to the EditUndoDelContent class for the undo/redo action.
Those 2 classes are responsible for freeing the ContentNode.
Change-Id: I977d8e418947bb48781f23575d62420260025e57
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161480
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Noel Grandin