Age | Commit message (Collapse) | Author |
|
Change-Id: Ifcfa48fc87f905a91470a5b0fd597b02f220784c
Reviewed-on: https://gerrit.libreoffice.org/671
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I9d39a9cfacf07aa596d047aee66c71b5ac6008ec
|
|
Instead of synchronizing the main list and the list of entries in the
dialog, just remember what was added and removed and only add / remove
those entries in the main "SvxAutoCorrect" list.
Additional add MakeCombinedChanges which adds and remove entries in
one call and only writes changes to the "acor" file once.
Change-Id: Idcc4c64d25e050c3f6eb9960a59c4a55d06b5ca1
|
|
Change-Id: Ie5e7aecd4f1c0e5b4dda9250ae755bf9210e048f
|
|
Change-Id: I6c2bc67a2b837adf9c12c5e93200fc1567732da3
|
|
...and some further clean-up.
Change-Id: If5dce53e382b56390c502d0d0d93fc06cbfe33ea
|
|
...with the same rationale as recent 543158edba6678d3d76eee983a9d4edd2a422fee
"Require XComponentContext.getServiceManager to throw instead of returning null"
(this helps find problems like 065a758d0c2b66c6683d648347b7a6cdef4a80f7 "Enable
experimental gtk3 plugin only via SAL_USE_VCLPLUGIN").
Removed comphelper::createProcessComponent[WithAguments] and replaced its few
uses with direct calls to createInstance[WithArguments].
Change-Id: Ia44b8656f74de88ef6eab3eb6bd597729b08e1c8
|
|
Change-Id: Ibf3dd31f2c213dca83a03773c430de841d2511de
|
|
* As UCB is only ever initialized with "Local"/"Office", remove this
configuration vector completely. The "create" ctor creates an instance
internally initialized with those "Local"/"Office" keys. Special (test) code
can still instantiate an uninitialized one via plain createInstance. And for
backwards compatilibity process startup still ensures to create an initialized
instance early, in case there is still code out there (in extensions) that
later calls plain createInstance and expects to get the already-initialized
(single) instance.
* XInitialization is an "implementation detail" of the UniversalContentBroker
service, do not expose in XUniversalContentBroker.
* ucbhelper/configurationkeys.hxx is no longer needed and is removed.
* ucbhelper/contentbroker.hxx is an empty wrapper and is removed; however, that
requires ucbhelper::Content constructors to take explicit XComponentContext
arguments now.
* The only remaining code in ucbhelper/source/client/contentbroker.cxx is
Android-only InitUCBHelper. Is that relevant still?
Change-Id: I3f7bddd0456bffbcd13590c66d9011915c760f28
|
|
Create a merged XPipe interface for this service to implement.
Which is backwards-compatible, but does not require creating a new service.
Change-Id: I682633c6252aab503eb2469c9bd2ba771f10bc4b
|
|
Change-Id: I19b3ba7c978e02ce865360f0411007525012149c
|
|
Change-Id: Ibd08fa09370580bff12f19f867219098f0d4980e
|
|
Change-Id: Id9bbb2bbcafe335eada3f36ae103a9074a56848f
|
|
Change-Id: Ifff80c025d9e3309190330931e1eb49e8ea7f9e4
|
|
i.e. since b35980d9b
seems remove, remove, delete was old pattern, new patterns ended up
as remove+delete, remove. Reorder to remove, remove+delete
Change-Id: I54ec8d0296e751110c516516465be2ac0615f6a1
|
|
Change-Id: I9ccf664e8f75a68b1b87c2b29ae617a90d0741a7
|
|
Change-Id: I5815bdc2ef0d7eff15d518f6d66e913e31592d83
|
|
Converts it to a template based on std::vector
Change-Id: Id7f89f494164c61a3a573cff443ac0e0488e93f1
|
|
Change-Id: I278cd66fb4819721bb473796c28598aaf04eb123
|
|
Change-Id: Idda2852c3e96ce15fde75d5a95369ec50a012410
|
|
Those classes don't exist. So remove friend class operators too.
Change-Id: I8e3b32db933dea7cbab86015f0c926df967511f6
|
|
Part of MultiLineEdit was moved down from stvools to vcl
with name VCLMultiLineEdit. MessBox uses it to display the
message in read-only mode. Some of svtools' classes - which
are necessary to implement VCLMultiLineEdit - were moved to
vcl as a whole, and their includes are rewrite.
Note: ExtTextView and ExtTextEngine classes would be leaved in svtools
if VCLMultiLineEdit is a template class, but two macros: IMPL_LINK
end IMPL_LINK_NOARG make it impossible to use template syntax.
Change-Id: I26543868d8081c225c7125404d23369de3c3afcd
|
|
Change-Id: I7f52d67d955896821f2c340fdd51e072b53fdd2f
|
|
In a language for which there is no dictionary available (no "ABC" check in
front of the current item in Writer's "Format - Character... - Font - Language"
list), "Correct TWo INitial CApitals" (from Writer's "Tools - AutoCorrect
Options... - Options") did not work (i.e., typing "FOo" followed by a space
would not change it to "Foo"). That was apparently a regression introduced with
51efaa592d4f54133c74e38cf294526bc78dffcd "Double-capital autocor takes
spellcheck in account." (I verified that with this fix words like "MPs" in
"English (UK)" are still left as "MPs.") Thanks to Caolán for help.
Change-Id: Ia76286e4ca73138ce3571145b9c40b031a4553ba
|
|
Change-Id: I7a32e8d7c21c1e87e1acab9020f9ecbb7e441f2c
|
|
...when running editeng/CppunitTest_editeng_lookuptree.mk
Change-Id: Ida1cbb16965138a42bec9e675b630bcbf2f6617e
|
|
LookupTree is a tree structure for fast autocompletion lookups.
Additionally the tree structure stores word probabilities, so each
autocompletion request returns a result with highest probability.
LatinLookupTree is an implementation which was designed to be even
faster and more efficient latin text, however it works with any kind
of unicode strings.
The tree structure was coded by Nico Weyand, Unicode strings support
and conversion to Libreoffice code structure was done by me.
Change-Id: I6549ee45d0952407b8a070f30ed0598fcb420aa7
|
|
Change-Id: Ifec201efc4e97baf2d36d66c4ae6967eadd6134c
|
|
so remove svxbox.?xx
Change-Id: I329b8468d05ea108ea9cfb57e3702cccfcc69227
|
|
Change-Id: I565b93a8dca6dadea7a6b3b9895c9d997acfb017
|
|
|
|
Probably using const_cast is "good enough" here for the exising use
cases of modifying elements in a sorted_vector; not exposing non-const
accessors in sorted_vector should deter adding these in the future.
Change-Id: I613d7d40041b01109fd1d54f51c105acf56ae34a
|
|
And convert it from a private superclass to a member. The code
is cleaner and easier to read as a consequence.
Change-Id: I35501a208c96615ce5797ad06d34d3b7efc2c4db
|
|
Change-Id: Ia3d1d8dbe100443410b80c3881f10ab51b2d0419
|
|
Change-Id: I4465281396f44f53ba87db0a405586294ea65076
|
|
... to store not Strings but derived SwAutoCompleteStrings with
something far saner: an abstract base class with virtual dtor.
Change-Id: I7d966f385dd41154ee1c4cdb43b56ff1aace9b5e
|
|
Change-Id: Ie1fa9b3cc2aef83ae9a82fbc110a08b2f298daef
|
|
Change-Id: I0799f22685609201dfb524c373d065b6184ed53c
|
|
Change-Id: I41d59d386b8f1fd5dc1fb9744a649085c66143f9
|
|
Change-Id: I6e242de572595fdf39553d76932bc0e953cd3a34
|
|
Change-Id: I31783eecc28cdc6f4d8c40841302d5338a2cd7be
|
|
Change-Id: I998d0f46020d3f5ea6fd387fbed8480e3d57e59a
|
|
Zemberek is a java spellchecker extension. With it installed the collecting of
spellchecker information on first activation of spellchecking is insanely slow
as the cache of spellcheckers is thrown away on each iteration through each
language known to LibreOffice.
So...
move the config updating stuff from editeng down to the linguistic layer. Let
the linguistic layer keep its spellchecker cache and listen to the extension
manager to know if an extension which might be a spellchecker one has been
modified and only throw away the cache on that event or if (existing
implementation) the config data for linguistics changes.
The polling of changed linguistic data in SvxLinguConfigUpdate::IsNeedUpdateAll
can be removed and leave it up to LngSvcMgr to load everything in its ctor and
keep itself up to date with its config and extension listeners.
Change-Id: I9c93d998928e2e7f5128c36771b3e450a8057cd6
|
|
Change-Id: I851c0ac078b57f07e0a58a9fb2119d11cc5048e5
|
|
Change-Id: Ibded6b0a72c9501d35fb884c93c505a2f716f678
|
|
getAvailableServices is very expensive, so halve the amount of calls to it that
we need. This should be logically equivalent
Change-Id: I5627ed539695fd837a497362cf9873debd254013
|
|
Change-Id: I870df7d4af666c1cb087cec6d4daebcba87ff8ab
|
|
Change-Id: Ie69b30094da25df23a36baca2c7723d6a41f48c3
|
|
This should do the inverse of ConvertBorderWidthFromWord.
Change-Id: If0b2a8a83a7faa6600a07ecfcb13a124d7cdeab6
|
|
Word uses a completely different definition of "width" of a double border
than OOo and ODF: for Word the width is apparently the largest of the 3
component widths, while OOo and ODF define the width as the total with of
all 3 components. The new border implementation in LO 3.4 was apparently
inspired by Word's double border definition, which resulted in
various import filter regressions, see the previous fixes:
36e43b52992735c622833e923faa63774b9e2f76
e2ffb71305c5f085eec6d396651c76d6daee3406
70a6a4d425558340bb49507975343a3e0a1bdde8
These fixes set the ScaleMetrics, which actually seems sub-optimal as
there is a ScaleItemSet function somewhere that apparently re-scales
all items in an itemset, which could undo the fixes.
Also, one of the fixes actually managed to break RTF/DOCX import
of double borders, as that ended up in the same code via the API.
This commit now reverses the change, so that the width of a border is
now always the total with of all components, which is (imho) much more
intutitive, and also leads to a consistent UI where selecting say 3pt
width has predictable results, no matter what the border style.
The border widths are now converted in the Word format import/export
filters (writerfilter and sw/source/filter/ww8), and various tests
were adapted to the new handling.
Change-Id: I50456c49b1a298569607e6c88f19f18441348ac3
|