Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Ie5fb706011ca600b42e5e2d3770e919b56347edd
Reviewed-on: https://gerrit.libreoffice.org/46938
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Previously we bypassed setting rects as dirty for a scene just
before we are about to create a 3D object. With this change we
do it earlier and suspend for the whole time we are creating the
scene - so we guarantee to o it for all 3D objects in that code
path. Aferwards we resume with setting rects and mark the whole
scene as dirty so we don't miss some update.
Change-Id: Ie4dec644102140edf282a2f5f6eb7fc9b81dbe48
Reviewed-on: https://gerrit.libreoffice.org/46901
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id927679c9f07f1dd820f4fdca9a45eb7aede037c
Reviewed-on: https://gerrit.libreoffice.org/46850
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1dc569d5a1667e3288fa64f16c22d39db130e906
Reviewed-on: https://gerrit.libreoffice.org/46813
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Theme overrides stopped working once ClrScheme::maClrScheme was
changed to vector, and colors were always appended to it.
Regression from f3121049828596b369e3ea844355d61666e49795.
Change-Id: Iae850dcabf57b12d8a564e84acf38d9988cfe963
Reviewed-on: https://gerrit.libreoffice.org/44242
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Icab5ded8bccdb95f79b3fa35ea164f47919c68fa
Reviewed-on: https://gerrit.libreoffice.org/46339
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I6fd7a9fed3a80c91a3766fceefd43c5db0aa5275
Reviewed-on: https://gerrit.libreoffice.org/46763
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5c3ffc03c26b3428f1f336e6ecba7838a1cf1157
Reviewed-on: https://gerrit.libreoffice.org/46764
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I84a7bcb891548416f0e1f1b20059f9b20c890d4c
Reviewed-on: https://gerrit.libreoffice.org/46686
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
3D objects using a E3dScene are traversing all object in the tree
when setting rects dirty. When we are creating objects, setting
properties and adding them to the tree we trigger setting rects
dirty which slows down considerably - more are added objects,
bigger the slowdown gets. So the solution here is to temporary
disable setting object rects dirty during creation of objects.
Change-Id: Id068cda9cb798d49b75bf4228cf6460f7e98c033
Reviewed-on: https://gerrit.libreoffice.org/46446
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
MultiPropertySet doesn't broadcast ItemSets as often as setting
each property separately. This can help when we create a lot of
3D objects.
Change-Id: I4eb842a5d8c43963bdceee84468593f5f6b47336
Reviewed-on: https://gerrit.libreoffice.org/46445
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I256a807dd2a4c81126b5a76f3d472e31b8224146
Reviewed-on: https://gerrit.libreoffice.org/46652
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I03f8f5fd656d62410821f2f2851f1c584c97d1f4
|
|
Change-Id: I214e13add371380701ae39403d90a574a63e495d
|
|
since cdecl is the default calling convention on Windows for
such functions, the annotation is redundant.
Change-Id: I1a85fa27e5ac65ce0e04a19bde74c90800ffaa2d
Reviewed-on: https://gerrit.libreoffice.org/46164
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and some more in base64.cxx
Change-Id: I31c9f23d3bd11f5482774e976a7c40025ffcfb86
Reviewed-on: https://gerrit.libreoffice.org/46157
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibad415d2c539b2438e4939c2c23f32d84a5a677f
Reviewed-on: https://gerrit.libreoffice.org/45948
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...and fix the fallout
Change-Id: Ie514bd95d5a9f990a887566619031e9844c40b92
Reviewed-on: https://gerrit.libreoffice.org/45195
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
first, since those are safer to change than virtual methods
Change-Id: Ie3b624019d75ee2b793cee33b3c5f64e994e8bfe
Reviewed-on: https://gerrit.libreoffice.org/45798
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I75c8224452ca9c3711a2ccaca9ecf549fa59cb64
Reviewed-on: https://gerrit.libreoffice.org/45549
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that are not composed of multiple tokens, like ("foo" "bar"). Also don't yet
warn about Boolean literals, which are sometimes wrapped in parentheses to
silence unreachable-code warnings.
To avoid multiple warnings about code like
f((0))
switch to generally using a set of ParenExpr to keep track of which occurrences
have already been handled.
Change-Id: I036a25a92836ec6ab6c56ea848f71bc6d63822bc
Reviewed-on: https://gerrit.libreoffice.org/45317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I93257b0ddd41c649875124d6d5c5faeaa431bae3
Reviewed-on: https://gerrit.libreoffice.org/45218
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I634363fb881776a089d4bcca366c8caebcdde117
Reviewed-on: https://gerrit.libreoffice.org/45283
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...which had been left out because "lots of our code uses this style, which I'm
loathe to bulk-fix as yet", but now in
<https://gerrit.libreoffice.org/#/c/45060/1/> "use std::unique_ptr" would have
caused an otherwise innocent-looking code change to trigger a
loplugin:unnecessaryparen warning for
pFormat = (pGrfObj)
? ...
(barring a change to ignoreAllImplicit in
compilerplugins/clang/unnecessaryparen.cxx similar to that in
<https://gerrit.libreoffice.org/#/c/45083/2> "Make not warning about !! in
loplugin:simplifybool consistent", which should also have caused the warning to
disappear for the modified code, IIUC).
Change-Id: I8bff0cc11bbb839ef06d07b8d9237f150804fec2
Reviewed-on: https://gerrit.libreoffice.org/45088
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iea72cb3a4bbf693096de46269f58259b5952eedb
Reviewed-on: https://gerrit.libreoffice.org/45024
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iac7d82a1c228734177be536e9a6c41803c03637b
Reviewed-on: https://gerrit.libreoffice.org/45035
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0525761b0d1359b3e0f249cef02e1818af95156b
Reviewed-on: https://gerrit.libreoffice.org/45037
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4f9b71ff7767e90987bb40358fc46ed5d1d571d0
Reviewed-on: https://gerrit.libreoffice.org/44944
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie9d637d701b77a549de3b00956f9c74ee8bd08c1
Reviewed-on: https://gerrit.libreoffice.org/44830
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I261f8a949ddd858dee196118bb42993a101a2a28
Reviewed-on: https://gerrit.libreoffice.org/44829
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
instead of spreading calls to Which() everywhere.
Change-Id: Ie32d106e44f5cb583908eeebe254ab8b8168ae61
Reviewed-on: https://gerrit.libreoffice.org/44760
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
use a strong-typedef template to give which IDs a type, which we can
carry around to do a
(a) little bit more convenience when Get()'ing them
and
(b) a little bit of enforcement of which PoolItem subclass each ID uses
Fix a bug in casting EE_PARA_BULLETSTATE to the wrong subclass
in AccessibleEditableTextPara::_correctValues
Change-Id: I015ce8b3b0f6d21308af182afa3caf122c877a5b
Reviewed-on: https://gerrit.libreoffice.org/44587
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I53b47cab5cbc603bf11adcda8ac2a8373eef26a8
Reviewed-on: https://gerrit.libreoffice.org/44695
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia544298334364ece3b3963a4adc00c5e01189b91
Reviewed-on: https://gerrit.libreoffice.org/44654
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Page <aptitude@btconnect.com>
|
|
Do not try to squeeze it into such.. especially if
SotClipboardFormatId::... enum identifiers are used in a user
object id context that is completely not related to the identifier
name this is totally confusing.
commit fb14be5f8f74f83ba89e15f891ddf1f753dcc62f
Date: Thu Mar 12 14:53:28 2015 +0200
create new 'enum class' SotClipboardFormatId to unify types
overdid with that.
Change-Id: I34b570be9f52b7b94ca8af6b23983393ac3a3a55
Reviewed-on: https://gerrit.libreoffice.org/44612
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I35afa226beb6fe4319313125c323d9f059837357
Reviewed-on: https://gerrit.libreoffice.org/44534
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib15931e415990b56367fe3e1c7cf3f22cc4826d5
Reviewed-on: https://gerrit.libreoffice.org/44529
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic80ca59abc3e104c7adf0c1eff1d16addf48bc8b
Reviewed-on: https://gerrit.libreoffice.org/44261
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6bdcde5fd416531e2cdd3c9ec160833f1022247c
Reviewed-on: https://gerrit.libreoffice.org/44246
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I10c7b62e6458062324367b94b207f776af79f598
Reviewed-on: https://gerrit.libreoffice.org/44129
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie3e8e174f3fa51331988481ec16d2d1a52bb9ece
|
|
Change-Id: Idc297808e1d95aecfd42e91a2aa7b99523ac7fb8
Reviewed-on: https://gerrit.libreoffice.org/43924
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Insert constructor everywhere, except a couple places that apparently
want to compare GetMapUnit().
Change-Id: I1910deb60562e5e949203435e827057f70a3f988
|
|
81892b2037453108b9bde1512a500cf3b2ce438a "loplugin:unnecessaryparen when
compiling as C++17, so the ParenExpr is no longer hidden behind
ExprWithCleanups/CXXConstructExpr/MaterializedTemporaryExpr wrappers" gave me
the idea to generally look though IgnoreImplicit instead of IngoreImpCasts in
loplugin:unnecessaryparen. However, that would still not look through implicit
CXXConstructExpr, so would still not have found the occurrences in
81892b2037453108b9bde1512a500cf3b2ce438a when compiling in pre-C++17 mode.
Therefore, let ignoreAllImplicit also look through CXXConstructExpr. (I am not
entirely sure in which situations non-implicit CXXConstructExpr---that should
thus not be ignored---would occur, but assume they would be underneath something
like a CXXFunctionalCastExpr, which is not ignored.)
Change-Id: I947d08742e1809150ecc34a7abe84cca5e0ce843
|
|
Change-Id: I5b455c684e7cd689d5160135246f3400363c7d40
|
|
Change-Id: Ibe5b5e03374419c2c23cd6559ab213d2dc2fcc66
|
|
corrected the error
Change-Id: Iece8f4c440c01eabe108ba4e9a93fe1fb919f0e3
Reviewed-on: https://gerrit.libreoffice.org/43445
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
as in interim measure for SfxTabDialogs we throw
away the TabPage if its not suitable for reuse
Change-Id: Ic5776ca3d2a8cb6bf41f33df01b211f81c62a842
Reviewed-on: https://gerrit.libreoffice.org/43134
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...instead of implicitly next to the including file, in preparation of
loplugin:includeform
Change-Id: Ie7ea504e6c7d7fbe1ae5f1f3b6996ad03feaee76
|
|
Change-Id: Icc45a7533510eaf4506be87819ac9f1e7d4bf9e2
Reviewed-on: https://gerrit.libreoffice.org/43167
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|