/distro-configs/

=db89f53c31af997b9bf422b0e784afba8d62a42e'/> db89f53c31af997b9bf422b0e784afba8d62a42e It is by now practically unmaintained, even bugreports in bugzilla have been already closed for it. AFAICT this used to be really used only on Windows, where it's no longer the default. There's still some OpenGL code left, because there are still two other places that use OpenGL. One is OpenGL slideshows, which reuse some of the base OpenGL code (and I've checked they still work even after this removal). Second one is OpenGL canvas, which it seems has never been finished or enabled (or so it most probably should be dumped too). Change-Id: I7ea5aef77ec252eb8e712d167db591209be84a13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107290 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 
It is by now practically unmaintained, even bugreports in bugzilla
have been already closed for it. AFAICT this used to be really
used only on Windows, where it's no longer the default.

There's still some OpenGL code left, because there are still two
other places that use OpenGL. One is OpenGL slideshows, which
reuse some of the base OpenGL code (and I've checked they
still work even after this removal). Second one is OpenGL canvas,
which it seems has never been finished or enabled (or so it
most probably should be dumped too).

Change-Id: I7ea5aef77ec252eb8e712d167db591209be84a13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107290
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
fix parsing of Vulkan version numbers 2020-09-22T12:58:41+00:00 Luboš Luňák l.lunak@centrum.cz 2020-09-21T14:44:32+00:00 bf62a89030aeb61cfdc032b167bc62ce6a3240dc The Windows+OpenGL handling pads the numbers so that .98 > 0.978, but Vulkan uses "normal" numeric ordering for versions. Change-Id: I766baf50e3505a96aa85163962400bb69c0acea6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103118 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 
The Windows+OpenGL handling pads the numbers so that .98 > 0.978,
but Vulkan uses "normal" numeric ordering for versions.

Change-Id: I766baf50e3505a96aa85163962400bb69c0acea6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103118
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Change OUStringLiteral from char[] to char16_t[] 2020-08-28T06:07:09+00:00 Stephan Bergmann sbergman@redhat.com 2020-08-27T09:40:59+00:00 33ecd0d5c4fff9511a8436513936a3f7044a775a 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> 
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>
loplugin:simplifypointertobool (clang-cl) 2020-08-04T21:28:17+00:00 Stephan Bergmann sbergman@redhat.com 2020-08-04T13:47:53+00:00 48a3d6b85e3c2858c281d5f258fcf2120ca84265 Change-Id: I6512e6e4217ef9084c74e46e3b4f1e8defbd1bec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100108 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 
Change-Id: I6512e6e4217ef9084c74e46e3b4f1e8defbd1bec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100108
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
replace usage of blacklist with denylist 2020-07-09T23:34:54+00:00 Thorsten Behrens Thorsten.Behrens@CIB.de 2020-07-06T01:01:51+00:00 493ae7a6bb0c3ad50615db0090e7ae8d391bc327 .. and a few cases of instead doing blacklist->excludelist where that made more sense. Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 [API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist [API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice [API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> 
.. and a few cases of instead doing blacklist->excludelist where that
made more sense.

Background and motivation:
  https://tools.ietf.org/html/draft-knodel-terminology-02

[API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist
[API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice
[API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList

Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
log properly the compiler used to compile Skia 2020-06-25T14:16:49+00:00 Luboš Luňák l.lunak@collabora.com 2020-06-25T08:35:00+00:00 2eeb6822110205f76eb908b5900526723cc8007c Using #define's directly from VCL will report the compiler used to compile VCL, which may be different from the one used for Skia. Also truncate the log file on opening. Change-Id: Iddf613613df20505f1abe1dd5468dcc8c7041410 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97090 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 
Using #define's directly from VCL will report the compiler used
to compile VCL, which may be different from the one used for Skia.
Also truncate the log file on opening.

Change-Id: Iddf613613df20505f1abe1dd5468dcc8c7041410
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97090
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>