Age | Commit message (Collapse) | Author |
|
Change-Id: I0a48a71fd1386fd5baf091e041bfa82255144779
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167760
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I56d6909dc3b1a7d45e4e3f45583321b1338838cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166063
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The events may be processed after the shell has been destroyed. This is
happening reliably after commit e2bfc34d146806a8f96be0cd2323d716f12cba4e
(Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable,
2024-03-11) when controlling LibreOffice from external Java scripts; but
obviously, it could happen before as well.
Now SotObject inherits from cppu::OWeakObject, instead of SvRefBase.
Change-Id: I73a3531499a3068c801c98f40de39bdf8ad90b2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164458
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If78b217698bd63895c6466744495ee22be8debc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160102
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
This reverts commit 7fc6063914432d58d86cfcbd728d967e7c86ebfd.
sberg noticed that there is a difference now:
there's a subtle difference now, in that if y was null originally, it would have thrown a (caught) exception, whereas now it will crash in the y.query<X>() call.
Change-Id: Idbb5a08d635d15b5ca63f4822eddf05fb0a5afa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since querying with exceptions is consideably more expensive
Change-Id: I968a9a40766b2abb0d3058549b0ed44011fd5716
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I09285716b6d17d8de95af91d822966520af35605
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iafcab8d5b21f9562838c3494cbfd75090dd6e010
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141152
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Jusify() normalizes the rectangle so both the Width and Height are
positive, without changing the location of the rectangle. It ensures
that the x and y coordinates will be moved to the top left of the
rectangle.
The name is strange, so renaming Justify() to Normalize().
Change-Id: Idbf163e65e52a798e38f785b8961b8042cf0cf2a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137379
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
See tdf#42949 for motivation
Change-Id: I97c1a0e8c7f26807b12e6062581066d09ea13086
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130114
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ib89b00c3dc8cd440e8a88906eea133becd1cef64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125509
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I0d233878ee49fcdc1338ec3bd700e5482d558163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120694
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I9113e589f74a119fc24e174e7e35036beb0d7acd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116643
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6eb3853883c724b5cb28bbf4debf6f56a587ff88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116515
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This unifies conversion functions to provide both floating-point
and integral overloads, with correct rounding for the latter.
Also sanitizing code it templatized to allow reuse if needed.
Change-Id: Ibe1c9fe4d5baa226c600445779dbaf7dc41a02cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110487
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I7cc5e98fe967da00228c1540ac28a0074e6d5e4c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110344
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
this way the cropping is kept after roundtrip
found while working on fix for tdf#128501
Change-Id: I5cf023b469407d5a70d83cbb5b499b2a1d6310e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107051
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
|
|
PPT can't store an OOXML custom shape with fill bitmap, PowerPoint
generates a fallback bitmap when saving to PPT.
We used to keep the bitmap and loose the custom shape geometry, but that
was changed with commit f4ba484183a1e7b9824f10580d633466c266828f (ooxml
import: supprt cropping to shape, 2019-05-13).
Fix the regression by going back to keeping the bitmap, a full fallback
bitmap (ala PowerPoint), would be more work, taking e.g. blurry shadows
(changing the shape position and size) into account.
Change-Id: I7192f912077f2de026573855dbebbdf576e39ebc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106219
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ie13e38c78b5e9a65b0dc572628f4fcc93b2c2a17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105530
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I67c1218d225f49ea9ce789433283ab85275e39a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104627
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
partly to flush some use of "long" out the codebase,
but also to make it obvious which units are being used
for angle values.
Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia4a62900536ea49583cc00853ff937fae35c2d7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103679
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: Ief34c9f041d491ffdb5efc2d888cf6f77de7b27b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94104
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Import/export the paragraph tabs without any text offset,
tabs are relative to the text box anyway.
Change-Id: Ife3b762e7581548e65500c16259a4481cc07a88f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94101
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
The main reason for the "home-grown" UpCast introduced with
904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for
css::uno::Reference" in 2013 was probably that we could not yet rely on C++11
std::is_base_of back then. A (welcome) side effect was that the derived class
could be incomplete.
However, specializations of UpCast relying on whether or not T2 is incomplete
are obviously an ODR violation if the type is incomplete in some TUs and
complete (and derived from T1) in others. And even if UpCast had internal
linkage, it would still be brittle that its behavior depends on the completeness
of T2 at the point of the template's instantiation, and not necessarily at the
point of use.
That means we should better base that ctor on std::is_base_of (which we can do
now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference
upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on
Clang and GCC if the completeness requirements are not met. This change fixes
all the cases where types need to be complete now, plus any resulting
loplugin:referencecasting warnings ("the source reference is already a subtype
of the destination reference").
Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7f5201e2ea6c74329336e16bf219630e38ff92cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92264
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
pPara was supposed to be the first paragraph, as before the
below commit.
Regression from d458adeed0c34fae26fe7f3d6ecc9b75b431922f
Change-Id: I50b993ff8f37fd5572d60fe5d103c3cf5e636a6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92105
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ifa384933569b27d0d08eb479bb95b799163ae386
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88450
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If83625845d8687f2749fce9699cb9bd6b8825be0
Reviewed-on: https://gerrit.libreoffice.org/79892
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibd809c8e48cd08123194071bf6f179a836f84cde
Reviewed-on: https://gerrit.libreoffice.org/77525
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use range-based loops, STL and comphelper functions
Change-Id: If4b6d464fc393049dc8d7e5c3faf1cf66b6a369a
Reviewed-on: https://gerrit.libreoffice.org/76480
Tested-by: Jenkins
Reviewed-by: Arkadiy Illarionov <qarkai@gmail.com>
|
|
Change-Id: I11e3dc250c140b03bbc2d2d83a448e40a1624fe3
Reviewed-on: https://gerrit.libreoffice.org/76519
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I8d1d7415c82c7d48f8d4bdf7b86e397fce01c015
Reviewed-on: https://gerrit.libreoffice.org/75908
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
which tends to interact in very weird ways with other code, for example
it makes Graphic appear to have an operator<
Change-Id: I335fe8f3644b710bc61291e625cbca7334a37716
Reviewed-on: https://gerrit.libreoffice.org/71532
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Also a few hxx files had missing headers and obsolete fw decls
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9a35c566d30678af445da3fec9570af235afb353
Reviewed-on: https://gerrit.libreoffice.org/68131
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I4f4b32e8bbe7601f10724c519226d06b04838e72
Reviewed-on: https://gerrit.libreoffice.org/67837
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8ce307b8c467ac1e3f19faca1df15a079bc14169
Reviewed-on: https://gerrit.libreoffice.org/67563
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ie212034c286146067c3ce49e62b2c47478ad7282
Reviewed-on: https://gerrit.libreoffice.org/65967
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Use range-based loop or replace with STL functions
Change-Id: I29ccc94be73ec3ab22c4915f4a18ad0247038cc4
Reviewed-on: https://gerrit.libreoffice.org/65204
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...after 7ffdd830d5fb52f2ca25aa80277d22ea6d89970b
"HAVE_CPP_ATTRIBUTE_FALLTHROUGH is always true now"
Change-Id: I54e5ff4e036a6bb3e5774d1c0524158aae18e937
Reviewed-on: https://gerrit.libreoffice.org/64800
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9fb8366634b31230b732dd38a98f800075529714
Reviewed-on: https://gerrit.libreoffice.org/64510
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
nDepth is only set in ParagraphObj::ImplGetParagraphValues
where the limit is checked, so the checks elsewhere are
unnecessary, and aren't comprehensive anyway
Change-Id: I566335da6b0cf13a76dcb247ad45c8b551af4456
Reviewed-on: https://gerrit.libreoffice.org/64223
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I954c12d9e1c493be6ac8c7b15076077b5bff5b74
Reviewed-on: https://gerrit.libreoffice.org/62811
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia31961d65592ebd2718446eaa931aab785b8ba65
Reviewed-on: https://gerrit.libreoffice.org/62457
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
redundant get() call on smart pointer
Change-Id: Icb5a03bbc15e79a30d3d135a507d22914d15c2bd
Reviewed-on: https://gerrit.libreoffice.org/61837
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and simplify callsites to use it instead of the current
"seek to end, find pos, seek back to original pos"
pattern
Change-Id: Ib5828868f73c341891efc759af8bd4695ae2f33c
Reviewed-on: https://gerrit.libreoffice.org/61738
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Additionally adapted EscherPropertyContainer's AddOpt
methods to be more safe and flexible. Added support for
SvMemoryStream. Changed Data handling in EscherPropSortStruct
to use std::vector<sal_uInt8>, adapted all usages and
converions throgh all modules. This makes memorty handling
for these parts much safer (no more local new-ops, no
longer delete[] there).
Currently there are quite some usages of nProp.size() and
&nProp[0] to access the data. but the base for further
changes to work more on std::vector is done.
Change-Id: I982225c5bfc06fdd9e195d18cd3c550d15f1d48d
Reviewed-on: https://gerrit.libreoffice.org/57061
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|