Calc imported Diagrams due to using mainly DrawingLayer
oox import code, but export, even of the unchanged
DomTrees, was missing (just never done). Thus in
versions before this being a Diagram was lost, it
just always was converted to a GroupHierarchy containing
the Shapes that were part of the Diagram.
Added to read the Diagram's name at Import at all for Calc
oox import, set and used now at the created Diagram.
Added to secure/save the DomTrees for the imported
ReplacementGraphic when importing oxx Calc, that was just
also never done, so it could not be exported as unchanged/
original data (and was not, so that was never noticed).
Added complete export of oox Diagram to Calc. This includes
unchanged versions, but also changed/added versions. This
may need more work, but own turn-around works already.
This mainly uses the same ExportContent, but that needed
some adaptions.
Doing this I also changed the ShapeImport of Calc to use
a single oox::drawingml::ShapeExport, before it created
a separate temporary one for every Shape that was imported.
Also added the checkMinimalDataDoms check to Calc oox
export that is already used in the other apps. As always,
there are huge differences in oox im/export for Calc
compared to the other apps, e.g. a completely different
Group ImportContext is used compared to Impress and I have
no idea why that is done.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Ib7c1b73f7f72599f6054d0cf9203f46980eec5cf
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1887
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit b1fbe49401e5e4dbe62ff25580ec7252c0376e88)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206019
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
...as emsdk 5.0.3 deprecated the predefined EMSCRIPTEN macro (see
<https://github.com/emscripten-core/emscripten/commit/506052bd8b4e23ded7f2351c62ca3b24d40c8cf3>
"Warn about usage of deprecated EMSCRIPTEN macro. NFC (#26381)"), causing
failures like
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:29:
> In file included from include/sfx2/viewsh.hxx:35:
> In file included from include/editeng/outliner.hxx:32:
> In file included from include/tools/color.hxx:26:
> include/osl/endian.h:66:15: error: macro 'EMSCRIPTEN' has been marked as deprecated: use __EMSCRIPTEN__ instead [-Werror,-Wdeprecated-pragma]
> 66 | #elif defined EMSCRIPTEN
> | ^
> /home/sberg/emsdk/5.0.4/emsdk/emscripten/main/cache/sysroot/include/emscripten/emscripten.h:35:66: note: macro marked 'deprecated' here
> 35 | #pragma clang deprecated(EMSCRIPTEN, "use __EMSCRIPTEN__ instead")
> | ^
To avoid confusion, also suppress the -D$(OS) in
solenv/gbuild/platform/unxgcc.mk that would unnecessarily keep defining
EMSCRIPTEN.
Change-Id: Ic1f187cf1c6417cd95d4092e9cea01a665bd1b2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/34
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 50291c2ed83bdb49bb827a4a12905d94b8c42035)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205167
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The top-level function already returns a boolean, make many of the
internal functions return false in case of failure and propagate that
instead of asserting in debug builds and continuing with bad input in
release builds.
Change-Id: I00c5f9552eb114af1f406f5f1c2ead50fe6b97e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201228
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
which is beneficial when we have a --enable-sal-log release build,
since most of the time the logging stuff will not be executed.
This is restricted to GCC because clang seems to have trouble
with the lambda binding in some places. (tested with clang 12.0.1)
I get errors like:
cppuhelper/source/servicemanager.cxx:775:40:
error: reference to local binding 'rImpls' declared in
enclosing function 'cppuhelper::ServiceManager::addSingletonContextEntries'
"Arbitrarily choosing " << rImpls[0]->name
Change-Id: I3fe6deb94996542b552af1e201f5a68f0136c680
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192151
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit f6b9b77d65c70ae77fa617c53e11d149a9fee1d1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192192
Tested-by: Jenkins
As described in include/sal/log.hxx, log areas may not
contain "_", and they need to be defined:
> For all the other macros, the given area argument must be non-null and must
> match the regular expression
>
> @verbatim
> <area> ::= <segment>("."<segment>)*
> @endverbatim
>
> with
>
> @verbatim
> <segment> ::= [0-9a-z]+
> @endverbatim
>
> For a list of areas used see @ref sal_log_areas "SAL debug areas". Whenever
> you use a new log area, add it to the file include/sal/log-areas.dox .
This fixes errors like the following ones seen for a --enable-rust-uno
build with clang plugins enabled:
/home/michi/development/git/libreoffice/rust_uno/uno_bootstrap.cxx:38:14: error: unknown log area 'rust_uno' (check or extend include/sal/log-areas.dox) [loplugin:sallogareas]
38 | SAL_INFO("rust_uno", "Initializing UNO component context for Rust binding");
| ^
/home/michi/development/git/libreoffice/codemaker/source/rustmaker/cpproduce.cxx:1011:14: error: unknown log area 'codemaker' (check or extend include/sal/log-areas.dox) [loplugin:sallogareas]
1011 | SAL_INFO("codemaker", "Struct member " << member.name << " UNO type: " << unoType);
| ^
Change-Id: I4ac11fc343f340488d15607cc7262ca57b6a4850
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190847
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
For Windows build, explicitly define HAVE_FILESYSTEM which forces
orcus to use std::filesystem for all filesystem related operations.
Also, pass to the ctor of orcus::file_content a filepath as
std::u16string_view on Windows to hopefully correctly handle unicode
filepaths.
Change-Id: Ie6f5403212e73c81f1a36db0413133d26a3a67f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189892
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
Tested-by: Jenkins
+returnsnull / -returnsnull
Specifies that a function might / might not return NULL. In the
positive case, the return value must be verified to be non-NULL before
it is dereferenced.
For example, the +returnsnull annotation in the following code
specifies that the value of fetch_ptr should always be verified.
Unverified values will be reported by the NULL_RETURNS checker (and do
not depend on statistical analysis).
//coverity[+returnsnull]
int* fetch_ptr(int idx) {
...
}
Change-Id: I827b665d3bc01546c8596457c50ebd860894f677
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189397
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
...so that different processes (e.g., when soffice.bin gets automatically
restarted) less easily overwrite each other's log files. The protocol (to
mostly stay backwards compatible and only use a single file name by default) is
to append a process ID iff the value of SAL_LOG_FILE ends in a hyphen, in which
case the process ID is appended to that value.
Change-Id: I516d7a286d029a16afc2f1379d5353f3f0eb5767
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188914
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
The user can now pass the available options
for each graphic type to export.
For example:
$ instdir/program/soffice --convert-to 'jpg:calc_jpg_Export:\
{"PixelWidth":{"type":"long","value":"1280"},\
"PixelHeight":{"type":"long","value":"1024"},\
"Quality":{"type":"long","value":"8"}}' --outdir /tmp Calc.ods
Change-Id: I77211805f4fd726da7d5fb0818ac422c3e9b6c96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186287
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This patch includes all marshalling and proxy handling code on the
.NET side as well as the native side needed for a fully functional
UNO bridge.
It also includes some changes and corrections to net_basetypes and
netmaker needed for the bridge to work properly.
It also includes the FirstUnoContact example in C# as demonstration.
Change-Id: I406932938a4415d24408fb41ddfa7d8eeb5d1f94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170916
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Because I want to make more symbols private, but that runs into a
problem with the special symbol "typeinfo for Foo" which is required for
dynamic_cast.
For clang, we can use SAL_DLLPUBLIC_RTTI to make just that magic
"typeinfo for Foo" symbol visible.
But for gcc, we are left with no option but to make the whole class
visible via <MODULE>_DLLPUBLIC.
(I have a feature request logged against gcc to support something like
that at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958)
But I also don't want to use <MODULE>_DLLPUBLIC, since that blocks
progress of reducing symbol visibility for platforms other than gcc.
So map SAL_DLLPUBLIC_RTTI to visiblity:default for gcc, which means that
only gcc suffers the negative affects of not having that annotation.
However, that runs into the problem that gcc does not like
visibility:default in a couple of places, so I have to introduce some
extra preprocessor stuff.
Change-Id: Ib4fc5c1d2a1f8cf87d5159a4b5684137ec061605
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164356
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Required for --disable-nss build on Windows, which needs the same fix as in
commit 71d4abc51b (-Werror,-Wdeprecated-declarations
(Emscripten), 2024-01-18).
Change-Id: I4206cbc0cb80be7ddee1c3f21de50d853828300e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163704
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... and use it in the new experimental ODF encryption mode.
https://www.w3.org/TR/xmlenc-core1/#sec-AES-GCM
Unfortunately it turned out that NSS PK11_CipherOp() does not work with
CKM_AES_GCM because it is initialized with "context->multi = PR_FALSE"
in sftk_CryptInit(), so the one-step functions PK11_Encrypt() and
PK11_Decrypt() have to be used.
NSS 3.52 also changed a parameter struct definition - see
https://fedoraproject.org/wiki/Changes/NssGCMParams - which is not a
problem for RHEL or SUSE system NSS since those are rebased, but it
is likely a problem for less well maintained Ubuntu LTS, so use
the old struct definition which evidently still works with NSS 3.94.
NSS 3.52 also added a new PK11_AEADOp() API but it looks like this
doesn't support incremental encryption either.
Change-Id: Ibd4a672db74b65b1218926ba35ff8d2f70444c7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160505
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
If this function returns null, storing a document will proceed without
reporting an error to the user, and lose all the data.
Change-Id: I0f9fd53702321e7997b28e12eb5bed3349bbcc13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160435
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Moves PasswordStrength bits that provide utility functions from cui to svl,
merging them with PasswordHelper there.
Adds password strength bar for the set master password dialog.
(accessible via Tools -> Options -> LibreOffice -> Security -> Passwords for Web
Connections)
Change-Id: I8dc1090a041f8388c2e139beb1d0d9a0beb8acb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159370
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
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>
Introduces new configuration options PasswordPolicy and
PasswordPolicyErrorMessage.
PasswordPolicy takes a regular expression. When set, it only
accepts passwords that match that regular expression.
PasswordPolicyErrorMessage is the label displayed when the
password does not meet the PasswordPolicy.
In the ideal case, it should contain an explainer of the
PasswordPolicy, so the user is aware of the requirements.
Save with password dialog had maximum password length enforcing
bits depending on the requirements of the saved file format.
These are still applicable in combination with the password
policy.
Also introduces a visual password meter under the password
entries. If the password policy isn't satisfied the password
strength meter is capped at 70%.
The entropy bits to password quality is taken as a linear range.
Where the range of [0, 112] entropy bits is mapped to percentage
[0, 100]. Entropy bits ≥ 112 are mapped to 100% since, according
to KeePass' info page, ≥ 112 entropy bits correspond to a strong
password: <https://keepass.info/help/kb/pw_quality_est.html>
Change-Id: I2e70adacf271916661219f702dfc217292a1b59f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158453
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
- FunctionBasedURPConnection is used to enable a client to open a URP
connection to a fresh Kit instance in COOL.
- This URP connector can be used with that and
https://github.com/CollaboraOnline/online/pull/6992 to use a Java Uno
Remote Protocol client over websockets
- For interoperability with existing Collabora Online websockets a
prefix (urp ) is added to each message sent and a similar prefix
(urp: ) is expected on each message recieved. This allows sending over
the same websocket as other data is being transmitted through. If you
are writing a bridge to work with this, you will need to add/strip the
prefixes accordingly
- This commit uses Java WebSocket
(https://github.com/TooTallNate/Java-WebSocket) to send data over
websockets.
Change-Id: I2bda3d0b988bef7883f9b6829eeb5b7ae8075f27
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151171
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
In the verious LibreOffice samples attached to tdf#156470, it appears
that LibreOffice spends a lot of time the GetTextArray() calls in
SvxFont::QuickGetTextSize(). So add logging to determine if any of
the GetTextArray() calls are returning unusual sizes.
Change-Id: Ie6f0fcc85396b47342b6a93180d4bc9873420931
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155072
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
LOKDocumentFocusListener keeps track of the currently focused
paragraph.
Also includes:
Author: Andras Timar <andras.timar@collabora.com>
Date: Mon May 15 22:06:10 2023 +0200
fix unused exception parameter 'e'
Change-Id: Ibfee099e4e9b724648d7500b9ebb4e8ab84989b8
and:
Author: Marco Cecchetti <marco.cecchetti@collabora.com>
Date: Thu May 4 12:11:53 2023 +0200
lok: a11y: focused paragraph info sent to client
For the currently focused paragraph the following data is notified to
client:
paragraph content, caret position, text selection start/end
These data is kept as an instance state so the client can request such
info at any time.
Change-Id: Ic1a3be0d93472300b1b6a91fb0de5bad87c031aa
and:
Author: Marco Cecchetti <marco.cecchetti@collabora.com>
Date: Sun May 7 11:52:14 2023 +0200
fixup! lok: accessibility event listener for focused paragraph
It seems it was not a good idea using a unique_ptr as smart pointer
for an instance of LOKDocumentFocusListener
Change-Id: I8e6b0f48fee3c5db3c9b074a663f7f3fb96a601e
Change-Id: I0fa400694f3129608228ade0b96e0b4e0aee87e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152488
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Andrea Gelmini