Age | Commit message (Collapse) | Author |
|
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
See https://bugs.documentfoundation.org/show_bug.cgi?id=100706#c1
Change-Id: I2e471f093ce18c8716108c4ba793c2124e489295
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90850
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
by making it extend std::vector - it wants to be a ref-counted vector,
so let it be, and we can simplify the usage sites
Change-Id: I93ff6ee1522da965e16223dca171401d36fd67b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90664
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I58ce75e711504553c8fc606382866754286f1aa7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89313
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ia5e342e763700b02f11e44cc04c10424fb14c55e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87603
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Idaba1b3731ee551ca747b6b8eb6bf49e33fae415
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87604
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ife14b8c3f7d121deb390deb5f405dd42d3016acf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86156
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I17b7881a28dc5b17d4051fe54cada2681e182873
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86159
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Id60895a48f59cb3c55db39d18cd27fed2108727e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86066
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4359b7042f98586e2c9f5529d83d769cdf3d033c
Reviewed-on: https://gerrit.libreoffice.org/85775
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* OldEntry in fpicker/source/aqua/resourceprovider.mm was apparently unused ever
since it got introduced with 00657aef09d854c74fb426a935a3e8b1fc390bb0
"migrate to boost::gettext"
* impl_throwError is used from multiple TU,
connectivity/source/drivers/macab/MacabStatement.cxx just missed the relevant
#include
Change-Id: Iba131da57aa20085bb1c634ba9a3a59566070abd
Reviewed-on: https://gerrit.libreoffice.org/84653
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
kCGColorSpaceGenericGray is deprecated and should be
kCGColorSpaceGenericGrayGamma2_2, and kCGColorSpaceGenericRGB is
similary deprecated and now should be kCGColorSpaceSRGB.
This fixes the "color skew" issue found in a variety of tests.
Change-Id: I8088b2377e03cde3f8e03e9d3778a40fc3081c4a
Reviewed-on: https://gerrit.libreoffice.org/82809
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I42d6546a9a400d8edb9ecef82614c6c88d4e6e83
Reviewed-on: https://gerrit.libreoffice.org/82806
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iea0f624e0f46c6555dace701a543787c48ab9549
Reviewed-on: https://gerrit.libreoffice.org/82754
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
For some unclear reason, for me at least, when I have built with Xcode
11.1 or 11.2 and run on macOS Cataline, I run into a crash caused by
boundless recursion related to the progress bar in the recovery
dialog. Not setting mbProgressNeedsErase to true for the "NWF" seems
to help.
Whether this has some unintended visually bad side effect I don't
know, but hey, it's just a progress bar, who cares if it in some
circumstances doesn't look perfect?
Change-Id: I6c990adde7689633b2c4b5aa42a4a07966565af2
Reviewed-on: https://gerrit.libreoffice.org/81874
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I97822e6843d6adef1af2435e186ac93d016e5322
Reviewed-on: https://gerrit.libreoffice.org/81202
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I31bf0f87cb66ac19dfa49566e9a190c8af8d408e
Reviewed-on: https://gerrit.libreoffice.org/80486
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I69e746d32b8a900fd9ee74ddc90b72cc6f9361db
Reviewed-on: https://gerrit.libreoffice.org/80484
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I39bdc93048733627a54c4f7b4b2e7df4f073ef25
Reviewed-on: https://gerrit.libreoffice.org/67424
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...since 5926b22b5dc33490d23d594b129eb8a70b94ffb0 "The SystemEnvData passed into
the canvas factories appears to be unused". (And the user-provided SvpSalObject
ctor can be removed, at which point the use in SvpSalInstance::CreateObject
should be written without "()" to avoid loplugin:subtlezeroinit.
Change-Id: I4392fa2d697b29c814d7b577a7b1f8c984c05e70
Reviewed-on: https://gerrit.libreoffice.org/80298
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
which is useful because our MSVC build will warn about this by default
Change-Id: Idcc0f08b69b6eda4dd2ab010a5fdb674787bebcf
Reviewed-on: https://gerrit.libreoffice.org/80184
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I85542ed9e631ad8589d3bc3469d171ab1d5cb4f9
Reviewed-on: https://gerrit.libreoffice.org/79396
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Iaf9b5107cf88390f62d5ca94bf985c77bcb8b7ad
Reviewed-on: https://gerrit.libreoffice.org/79048
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I8bc5a73a91f28fcfd22ef716e9cf87d53997b1ad
Reviewed-on: https://gerrit.libreoffice.org/77337
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Idb183e0ee9cccf0e4da16ff984ccf9b57eea0f9e
Reviewed-on: https://gerrit.libreoffice.org/77273
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Icb9d9e1cd21e2506e36fe40a3b93b6a2521a868c
Reviewed-on: https://gerrit.libreoffice.org/77239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I545154bddfd29194630d744b4aa4f5c385321531
Reviewed-on: https://gerrit.libreoffice.org/77138
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ifad405b05142ce61673f22ec3160f50314419ce7
Reviewed-on: https://gerrit.libreoffice.org/75680
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I53a019f05978bab62ad0da3d0eb08f37f8ec1e18
Reviewed-on: https://gerrit.libreoffice.org/74414
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
I don't understand why WidgetDrawInterface, which is basically a
copy of the SalGraphics native controls interface, duplicated it,
instead of cleaning things up.
The whole commit message of commit 8fcfa3853a81, which added this
code, is just: "custom widgets: Custom Widget Themes". That's it.
So this patch does, what the original one skipped: replacing the
SalGraphics interface with the WidgetDrawInterface. One result is
the addition of handleDamage to SalGraphics to correctly handle
the damage done by a custom widget theme to the underlying
SalGraphics implementation.
Change-Id: I5fda1a64b28e6560fb3c62e02b6dcda827f698e2
Reviewed-on: https://gerrit.libreoffice.org/74118
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This reverts commit a46a257794f1f53b294735fc876c394be23a3811.
Too many issues, I'm going to try landing this in smaller pieces to make it easier to fix regressions
Change-Id: Ie5e8979838017af86c119c887b580385ba068d54
Reviewed-on: https://gerrit.libreoffice.org/73859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This is the width part, the height part will come next.
Instead of storing "empty" as a special value (which is easy to get
wrong, eg. some image filters pass in that special value, expecting it
to be a valid width), just use separate boolean values for width and
height empty.
Also lots of code was calling GetBottom() or GetRight() on an
empty rectangle, getting back that magic value and doing calculations
on it, resulting in completely bogus data.
So
(1) make the various Rectangle methods do something reasonable
when the empty flags are set
(2) fix various other code to handle empty better
(3) assert when code accesses Bottom or Right and the empty flag
is set.
Change-Id: I1163378cd2773dd8b386210f83400bb6b4701069
Reviewed-on: https://gerrit.libreoffice.org/73564
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icbfc9276e09f2d50647c4e800b6d688d978b875b
Reviewed-on: https://gerrit.libreoffice.org/73632
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I7c46c231f720c7d35a24e19833fb3239a31946ef
Reviewed-on: https://gerrit.libreoffice.org/73589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I404a8364a4c7f8d48533fb3c7757a5b7798de9d8
Reviewed-on: https://gerrit.libreoffice.org/73588
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
No need to use objc_msgSend().
Change-Id: I56c824e3206c37be4b60fb7d82b65c9d5e89958b
|
|
Based on the corresponding macOS code. Work in progress. The image
support ifdeffed out still (because it uses some macOS specific APIs
for which I couldn't right away find the equivalent iOS ones).
I made it much simpler than the macOS code. I dropped the keeping of a
local in-process clipboard completely. Firstly, as far as I see, the
iOS clipboard API (UIPasteboard etc) does not even offer the
possibility to separately offer some formats and actually provide the
data on request. Secondly, we must be prepared anyway that the system
can kill an iOS app at any stage while the user is using some other
app, so we need to make sure everything that is copied goes onto the
system clipboard right away anyway.
I had to disable the copying of HTML to the clipboard as that lead to
a mysterious assertion failure. See comment in
DataFlavorMapper::openOfficeToSystemFlavor(). But RTF seems to work
well, too. I assume RTF is what gets used for cross-application
copy/paste (and cross-device, even, through Apple's Universal
Clipboard thing, where you can copy/paste between your Macs and iOS
devices on the same network).
I am not sure how relevant the various application/x-openoffice-foo
formats are.
Change-Id: I174495e33d86fc3990996c229243c05d6cbfcda7
|
|
Seriously, such default values only serve to confuse the code reader.
Change-Id: I478442514baac3159ea0ae20132222ae58b38b8c
|
|
Change-Id: I44ee257a8a196e8f2372dd01776c0c7c5193ad0a
Reviewed-on: https://gerrit.libreoffice.org/72436
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I3088e0b2f6c54f272fd29d7a6069e8231b207666
Reviewed-on: https://gerrit.libreoffice.org/72435
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
On macOS it is possible to copy from a PDF a subset of a document,
which will be transported as a new PDF document containing the
subset.
LibreOffice didn't support PDF as a valid clipboard format and
previously it also didn't support showing PDFs inside the document,
so in such cases it copy-pasted a low resolution bitmap. The result
wasn't good.
As we are now able to display PDF documents as Graphic in LO, we
can also support this use-case. This adds support for the PDF
documents as a clipboard format in general and to the macOS
backend. This commit only adds support for Writer.
Change-Id: Ib982b55391b390ae06974b4ad836e376dd722a4c
Reviewed-on: https://gerrit.libreoffice.org/71364
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Iff472d81f7ef0a3371a0735f025a72c595321efd
Reviewed-on: https://gerrit.libreoffice.org/71352
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I7625adbf365aa908c072ca42060e926569629044
Reviewed-on: https://gerrit.libreoffice.org/71279
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ief2636425712f60cfc6e8f68ee0d3fb01608d8ba
Reviewed-on: https://gerrit.libreoffice.org/71317
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
if we're doing a find/insert on a set or a map, it is better to just do
a conditional insert/emplace operation than triggering two lookups.
Change-Id: I80da5097f5a89fe30fa348ce5b6e747c34287a8d
Reviewed-on: https://gerrit.libreoffice.org/70937
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I50cacafa8bbd90fef15603f0bde3f653f78393ea
Reviewed-on: https://gerrit.libreoffice.org/69305
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1576282b0a0a3af8ae14c04725d9c4900073f2c4
Reviewed-on: https://gerrit.libreoffice.org/68758
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1ed43bab00a5bc456032410ccf32b3fd64cc970c
Reviewed-on: https://gerrit.libreoffice.org/68419
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This first step only affects GTK3, later we will extend the support
to other platforms.
Note that these images are derived from the OSX PNG files, not the header-file
encoded data we currently use for gtk/gtk3.
Also rename the files to more useful names.
Change-Id: Ia13a3f2ac35b06672aff724f4cf5bdcd823f6342
Reviewed-on: https://gerrit.libreoffice.org/67528
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
sal_uInt32 seems reasonable given that this is the number of rectanges
in an image.
And then convert all of the other BeginSetClipRegion methods to use
sal_uInt32 too.
Change-Id: I85a712ec823662ac30f3859051e2b974fb99775e
Reviewed-on: https://gerrit.libreoffice.org/68343
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|