Age | Commit message (Collapse) | Author |
|
so we can take ownership of the original instead
Change-Id: I26fd4303a3b205df309f91bfa5bcddbbc41dfd7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104173
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
the problem is that since...
commit 319d8be9dad248a3ced5ac311e0b20ec3ed4cef7
Date: Tue Nov 22 16:21:20 2011 +0000
tweak experimental gsoc multiline input bar, better resizing, enable scroll
that uses SetNofifyHdl to try and keep its scrollbar up to date, but that
SetNotifyHdl is also used by a11y to listen to the editengine and only one can
be set at a time, so with a11y enabled (the gtk default case) either a11y works
or the multiline scroll doesn't or vice versa.
Seeing as the a11y case is the very complicated case, leave a11y alone and
plot a route to disentangle the straightforward calc multiline edit from a11y.
Change-Id: Iedc7ffc39940354e8a05c0620944f617eee6b550
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104080
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I2973128a9c6c53187e1da400d1a5df763d515596
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104020
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I25ca760ae15114ada621d928997a7117401c75d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103811
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5c731161768d09d021db5c353de816e173159096
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103764
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
even if there is no text yet we should update the IM cursor
position if asked for it
Change-Id: I9c3b9eef9f58180b00a8276d25fad83400a92043
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103751
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
for the generic case first
Change-Id: I10bd707900b54c70c9bda79d5d09532cc159779e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103692
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Iac6b319700d610b5a1debff0a633172b2411c40e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103161
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
working:
a) bullet preview
b) writer rendering
c) save to odt
a) load from odt
Change-Id: I2f85576389fe4f0437f81799c14dfd98c8c40b2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103129
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
When user changes font size of selected text, markers and highlight rectangle should be updated.
impedit3.cxx: Line had no effect, removed.
Lokitsearchtest.cxx: Test had bug.
Other changes: LOKit code is separated. Now callback_text_selection is fired when font size is changed (Calc). On Writer it already behaves that way.
Change-Id: I9b7e3224ad162bfb7d8f0853b6cb17b4feafa0cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101193
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102465
Tested-by: Jenkins
|
|
This commit was carried out by a Python script, source of which
is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97.
Change-Id: Ib435cc551e1fa301bf4ee3e796241e6b9219dc87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102576
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I5aaf606b684b69641a872b3405b4d4d378289ad4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102466
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0d225f3defe3996b89640ddd4f61db1412f85dc9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102249
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Idbcce18029944ab884cdde03e21190cbb574a00f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102005
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
It passed "make check" on Linux
Change-Id: I7596db11cae77c2dcadd740c44cc72fd5dbceb9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101619
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I400ee3cb9f0a98804d98e25d0164fa5148b79191
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100424
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101385
Tested-by: Jenkins
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I58c510121a9f535b2a31854f10b5f6535554d379
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100988
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
look for expressions like
!(a && !b)
which can be expanded out
Change-Id: I72515a9638762b050f9a258c08da39ebfa2ef8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8fdf9833dede6f4c9ba4bbb76b9ab9b6b419f155
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100722
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
we're not in DOS anymore, Dorothy
Change-Id: I79926e0d694163940ba7ebf20419724dd0a486f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100721
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4f05b6a35010e661ea77f3e4b83302d2ec74d227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100405
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia69fb105c6cc661ac94a360d47655b3faa9d6bb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100618
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idaeed33df4f1dd1b2acbdaf8a895c5d56c3ca14c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99980
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Recheck after 7-0 branchoff
Also drop the now unused file include/vcl/field.hxx
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I3b7774a043a2c99531e1c76b531df4358699bba7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99440
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I240bff8de9489d3c0c9c9be6b31ce7e15661bff8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98922
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
- document key combinations in README
- dump data into workdir as editenginedump.log
- move as static function into EditEngine class
- get rid of the EditDbg class and editdbg.hxx
Change-Id: I965f0143a9a275a289b202f54c0ea65da63c52f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97873
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I67e82a3ec9128a486ef882f803c900b7c94a4529
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98573
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
For Calc, this means the LOK clients get selection rectangle coordinates
in print-twips when special positioning is enabled.
Change-Id: Ib26341f888cedcde2e2755ea57be0623884bb097
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98132
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Background and motivation:
https://tools.ietf.org/html/draft-knodel-terminology-02
Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
We can't use the transformed version of editeng origin, since it need
not be in client view area depending on text alignment, which is
unusable as far as the clients are concerned. Top-left corner of
output-area is always guaranteed to be in client view area independent
of text-alignment settings.
Change-Id: I5bd20d2b52e146371de4b605bf7934b7e7d6fc5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98131
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
the EditView's output-area needs to be tweaked temporarily to render it
to a tile which is meant for another view.
Change-Id: I2b8fc1986c247ce65c18ea64e3b43d25625c7e9c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98129
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Paper size for the EditEngine is calculated based on per-cell pixel
alignment. So lets use the exact print-twips version whenever we need it
to compute/adjust output-area and visible-area of EditView.
Change-Id: I7da6db9363d09965315ff5ca9d01f0fea141a533
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98130
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
Change-Id: I7749951d829eb8aaeacdca0fd66d41cf9d6a1613
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98251
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
for computing edit-cursor messages if available. For Calc, this means
the LOK clients get edit-cursor coordinates in print-twips.
Change-Id: Ib11f3653e626ba8db7ddbc9bc2b4e071de7b705e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98121
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
This is meant for Calc. In Calc, all positions in twips are computed by
doing independent pixel-alignment for each cell's size. To allow
print-twips coordinates in LOK messages specific to EditView, this patch
introduces new methods to set/update both 'output-area' and
'visible-doc-position' in print twips coordinates, which are stored
separately.
Change-Id: Id165966c970fa26c79d583f435dccd62c7eb1f0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98120
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
typing " inside primary quotation marks: use
the correct order of the double angle quotes:
„... «quote» ...”
Add also Aragonese, Asturian and Catalan to the
"<<" and ">>" replacement.
See commit 57f07b1d7378d218648667c5b1315cc8ad905875
(tdf#133524 AutoCorrect: support double angle quotes).
Change-Id: I2e80cc45768eefa3eb62b446ca822ee6c46f7242
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97970
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I02aacffcac30d48f79fd8d2640392aa3f1214b41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97826
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic5294dc53b1a7b6c654619cde8ef5133c222ae1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97558
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I54f0e2864cb4ef00fea8f9e4369a1f76721e7503
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97369
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
of new localized options added by
commit da64ec8c8a91db6a6ec9657898f081d5ee67e739
(tdf#133589 AutoCorrect: transliterate to Old Hungarian)
and commit 77b213890a96d144d9cfacdfd35ac0bba68b9f7a
(tdf#133524 add option to angle quote AutoCorrect)
Change-Id: I39f97cfc5a9deb7cbe92d175b2e59ba2ab8a2707
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97266
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I8181697f608f8472482905b21328744fe7909349
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97196
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and Ukrainian at "Single quotes" replacement
outside of second level quotations.
For example:
„quote' -> „quote‘
but now
apostrophe' -> apostrophe’
instead of the bad
apostrophe' -> apostrophe“
Change-Id: Iad69b7f88ab9677f25ee0f806d035e16cdebe29b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97096
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Note: << and >> replaced with single angle quotation mark
‹ and › in Swiss French, according to the apostrophe related
changes in tdf#116062, see
commit b9910e87de4eea1cb3684bb7af8e58d681cbe809
(Resolves: tdf#116062 revert [fr-CH] to use previous single
quote characters)
Change-Id: I84c54b7c12d2b3a2a53e4daf876bfba11985fdea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97095
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
in Localized Options page of AutoCorrect Options
dialog window:
[x] Replace << and >> with angle quotes
Note: this is optional part of Double Quotes replacement.
Change-Id: Ib0c7e8837a89c3772c5db76720811d440e62183a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97094
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
(and where sticking to numeric '\x0D' is probably cleaner anyway)
Change-Id: I614c57a4de74bf688c498e9bff043ca2eee04cb2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97033
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9384c03d9e616ac94256d679e3d545afe6794360
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95257
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia14a1391cbc40b98d24e37c3a54b16871441fc78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95399
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|