(1) Migrated all still existing binary load/save stuff
in SfxPoolItem to legacy files. Isolated from Item
implementations. Adapted all usages. No more methods
Create/Store needed, also GetVersion removed

(2) Removed operator= for SfxPoolItem. Adapted all
usages. Goal ist to handle Items more as Objects
('Object-Oriented') in the sense to move/handle
instances, not to copy one instance over another one
(which is more and more problematic with hard to copy
content as UNO API stuff or similar). This lead to
much more usages of std::shared_ptr which correlates
well with future plans fr Items (see dev branch).
Next logic step will be to also remove copy constructor

Linux build and corrections done
Fixed Writer test and removed unused defines
Fixed another unused m,acro
Started to unify the AutoFormat stuff
Changes to OUString constructor usages, tests completely
No idea why, but SfxStringItem constructor which
takes a OUString& now insists of not getting ::OUString's
handed in - changed all 'SfxStringItem.*OUString.*".*"'
accordingly

Change-Id: Ibed7358b18fb019994a7490332b9d797a6694c29
Reviewed-on: https://gerrit.libreoffice.org/71075
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>

Change-Id: Ibe76cc8950e26f0b78425f91faae2f44b5474ea7
Reviewed-on: https://gerrit.libreoffice.org/71264
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: Ie608aea0cd65d6bc6a3c5d700650ac3b9d3241a9
Reviewed-on: https://gerrit.libreoffice.org/70998Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Similar to 88be8aa1

Change-Id: Ia6f725fd6c6cee3135191a998ea43c1e6f90fc23
Reviewed-on: https://gerrit.libreoffice.org/71287Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Change-Id: If10507a51cf4b680034e225ec011f43f624ca34c
Reviewed-on: https://gerrit.libreoffice.org/71259
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ib4b6031b31500a8a2086721124b5b8f554f7c1c5
Reviewed-on: https://gerrit.libreoffice.org/71296
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

...at least since 7a08bfea "tdf#122244 Put
InfoPlist.strings files at correct places on macOS", though it wasn't under
Contents/ at least as of lately, anyway.

The code to remove it had been added with
f345a2c5 "We don't want those
bin/InfoPlist_*.zip files in the app bundle".  I don't know how to do a
--enable-macosx-code-signing build on macOS to verify that it can indeed be
removed, though.

Change-Id: I61d91bd47abf8f4b5d9e117d9943e0682ebef2cb
Reviewed-on: https://gerrit.libreoffice.org/71298Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: I9d0204161a0efe91ebcddaf5b2931ab156221b79
Reviewed-on: https://gerrit.libreoffice.org/71283
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Icd00e2aaa5932564668cd12ce4ee63aecc34419a
Reviewed-on: https://gerrit.libreoffice.org/71226
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I1f46c6043b3263ef983991ffa4aa0418006d55a7
Reviewed-on: https://gerrit.libreoffice.org/71292
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I54c1f438a755267db0896637c79f915de9113f83
Reviewed-on: https://gerrit.libreoffice.org/71074
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>

follow-up of 10c93414

Change-Id: I2085173dffd71dbbc68a0574400bebe132626dd9
Reviewed-on: https://gerrit.libreoffice.org/71284Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Change-Id: I28e8d8e4ab940ae838fc555702b5580dc76931dd

InfoBarType::Success adjusted to the newly added successbox
see also I829218d014c13698d075e0fcd3162801d31ba093

Change-Id: I6b542928f3d1d1940b9da36b4c40cd8af97fb2f5
Reviewed-on: https://gerrit.libreoffice.org/71285
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>

Change-Id: I7fb59039429361dad04fb68507f40545f9c4dd6d
Reviewed-on: https://gerrit.libreoffice.org/71290Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

* Update translations from branch 'master'
  - update translations for master
    
    and force-fix errors using pocheck
    
    Change-Id: I04522500fe14e0d09925b196ccf7b7f94f3bfe64
    

Don't know how this got broken, presumably somewhere along the line from
01344a8c "convert sysui to gbuild and add to
tail_build" through 4430ace3 "tdf#90753:
AutoInstall more packages" to the current state, where a spurious bin directory
containing InfoPlist_*.zip files containing (empty) InfoPlist.strings files is
placed in instdir/ and in the root window of .dmg files.

As discussed in the <https://developer.apple.com/library/archive/documentation/
General/Reference/InfoPlistKeyReference/Articles/
AboutInformationPropertyListFiles.html> "Localizing Property List Values"
section, those InfoPlist.strings files shall apparently be placed into the
Contents/Resources/*.lproj/ directories.  (And the zip wrappers were presumably
needed in the past to transport their payload to the proper places in the
installation set, and are now obsolete.)

The list of Apple language IDs for the *.lproj directories was already
duplicated in Makefile.in (test-install target) and
solenv/bin/modules/installer/simplepackage.pm (sub create_package).  Ultimately
those lists should all be consolidated.  Also, mapping from our language IDs
(see solenv/inc/langlist.mk) to the Apple *.lproj ones needs some fixing (e.g.,
from zh-CN to zh_CN), and it is not clear to me why the old code explicilty
added en-US to the gb_WITH_LANG list of languages for which to generate
InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the
non-localized strings stored in Info.plist itself).  But as mentiond, those
InfoPlist.strings files are all empty anyway (which may be due to another bug?),
so it shouldn't matter much---at least for now---what
Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an
installation set.

Change-Id: Iaadce2375ed319928891bace44f9866622ec3084
Reviewed-on: https://gerrit.libreoffice.org/71277
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

I faced the same problem in
https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/commit/?id=f631db9e5e83706ed2678fb4db737700dd623a1b

Change-Id: I1adcc418e0efa7e77e1dda5b9dccd7c55cb5267f
Reviewed-on: https://gerrit.libreoffice.org/71280
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: Ia7dc9879aeaa978d1cb1b0573fb69bd63bd5d4e0
Reviewed-on: https://gerrit.libreoffice.org/71278
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: I16dfde335816053e5821d5e975b27b6e4819b1a8
Reviewed-on: https://gerrit.libreoffice.org/71135
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Change-Id: Ie5310d3c3d4fde59a0718dbda228c638b7e0c366
Reviewed-on: https://gerrit.libreoffice.org/71235
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I829218d014c13698d075e0fcd3162801d31ba093
Reviewed-on: https://gerrit.libreoffice.org/71265
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: I1a3396d434f6cc5bb615bcb2fe06a819bc11c013
Reviewed-on: https://gerrit.libreoffice.org/71256
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Similar to 88be8aa1

Change-Id: I616ad50bfdc4c11be9b377e218636092adc3bd42
Reviewed-on: https://gerrit.libreoffice.org/71249Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>

Change-Id: I350c2c96cd178878ae687dd5214fcabfcf7675e7
Reviewed-on: https://gerrit.libreoffice.org/71254
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

This is the first try of a new TabBar look - borders have been
removed, selected tab doesn't change the font to bold, adjustment
to the selected tab line.

Width and height of a tab item has been adjusted to make it
better to fit the icons in and to not be so cramped.

Draw "protected" status of an tab icon (in Calc) as an icon and
not as a unicode glyph.

Change-Id: If2ee930a573343166fbe9efcd94ae5159a620f22
Reviewed-on: https://gerrit.libreoffice.org/71238
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

Seems like this is a somewhat pathological document, has lots of
duplicated ranges. Checking for duplicates makes it load in <10s on my
machine

Change-Id: I25da24e0f8b1d4ad99d00474be168c75586ea579
Reviewed-on: https://gerrit.libreoffice.org/71251
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

Change-Id: I6607ef2c9ca0860643cd57f9bde171ea1a7ca3af
Reviewed-on: https://gerrit.libreoffice.org/71269
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>

When 'QFileDialog::Directory' is set, the native
Plasma QFileDialog does not consider the clicked
directory to be selected, but rather the base directory
shown in the dialog, s.
https://bugs.kde.org/show_bug.cgi?id=406464 .

Therefore don't set the option when in a KDE Plasma desktop
environment (which the kde5 VCL plugin also doesn't do).

This works around the above issue in the Plasma desktop
integration.

Change-Id: Ib3d0978ab56b6e50ee45f7ad997ec051b35faf54
Reviewed-on: https://gerrit.libreoffice.org/71223
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>

Change-Id: I7db23f84a3de4772b38c9538704f501a9169ce09
Reviewed-on: https://gerrit.libreoffice.org/71267Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: I02e84f888950c85e19f50ffe7ace52e71a24e397
Reviewed-on: https://gerrit.libreoffice.org/71266
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

...but only with old MSWord compat flag SplitPgBreakAndParaMark.

All of the other cases (COLUMN_BREAK and non-empty runs) split
the paragraph, so why not here?  This document shows it is needed,
but only for SplitPgBreakAndParaMark documents.

Note: Word 2003 doesn't display "modern" docx well in this regard.
It adds extra paragraphs where it shouldn't. There are already
example unit tests that ensure that extra paragraphs aren't written
for SplitPgBreakAndParaMark == false.

The actual bug's document is not related to the compatibility flag.
That will be handled in separate commit.

Change-Id: I27399780c909663f9a2b21974a5b385bea67f9ec
Reviewed-on: https://gerrit.libreoffice.org/70835
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>

Move TableColumn Java tests to C++ for ScTableColumnObj.

Change-Id: I3f17fa1f25c2676124b56c384364e36736fac849
Reviewed-on: https://gerrit.libreoffice.org/71261
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Change-Id: I08d5b060b6756a89972eeec57c1f9c85e6f65500
Reviewed-on: https://gerrit.libreoffice.org/71262
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Change-Id: I90ea66c8da67c4fcdc8143f1cc94e80db207ee31
Reviewed-on: https://gerrit.libreoffice.org/71257
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Commit a51b7a1c (tdf#103831, tdf#100986:
Force using GDI when needed, 2017-03-03) noted that the DirectWrite text
renderer doesn't support stretched text, add support for this now by
setting a DirectWrite transform matrix that only does horizontal
scaling.

With this, tdf#113076 is kept fixed, but at the same time manually
stretched text keeps working. Previously the glyphs of the text had the
correct size and position, but the glyphs themselves where not streched,
but simply aligned to the left.

Change-Id: I8fe8e74d3edc0d71ed2f16fcce66c6f5009ed264
Reviewed-on: https://gerrit.libreoffice.org/71245Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

For one, it is deprecated since Java 9, and for another it causes a
NullPointerException when called from the JNI Invocation API (i.e., without a
Java caller frame) at least with some Java 12.

(Found when doing a test build with Java 12 and JAVA_SOURCE/TARGET_VER
explicitly configured as 7 with d365f363 "Allow
to pass JAVA_SOURCE/TARGET_VER into configure".)

I have entered information about the NullPointerException at
<https://bugreport.java.com/bugreport/start_form.do>, but haven't heard back
yet, so duplicate that information here:

Issue Type:
> Bug

Component:
> Core Libraries

Operating System:
> Linux 64-bit

Java Release:
> 12

Synopsis:
> Calling java.lang.Class.newInstance from JNI Invocation API causes NullPointerEx

Description:
> I can reproduce this with the OpenJDK 12 RPMs on Fedora 30, but from looking at <https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/java.base/share/classes/java/lang/Class.java> it looks plausible that it is a common issue that Reflection.getCallerClass() returns null when java.lang.Class.newInstance is called from the JNI Invocation API, and that null is propagated to jdk.internal.reflect.Reflection.verifyMemberAccess as parameter currentClass, which dereferences it at <https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/java.base/share/classes/jdk/internal/reflect/Reflection.java#l130>.
> This is known to have been working with older OpenJDK (at least 1.8).

Steps to Reproduce:
> Compile the provided test.cc with `g++ -I/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/include -I/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/include/linux /usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/lib/server/libjvm.so test.cc` and run it with `LD_LIBRARY_PATH=/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/lib/server ./a.out`.

Expected Result:
> exit 0

Actual Result:
> Exception in thread "main" java.lang.NullPointerException
> 	at java.base/jdk.internal.reflect.Reflection.verifyMemberAccess(Reflection.java:130)
> 	at java.base/java.lang.reflect.AccessibleObject.slowVerifyAccess(AccessibleObject.java:673)
> 	at java.base/java.lang.reflect.AccessibleObject.verifyAccess(AccessibleObject.java:666)
> 	at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:638)
> 	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:490)
> 	at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:166)
> 	at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:404)
> 	at java.base/java.lang.Class.newInstance(Class.java:590)
> Aborted

Source code for an executable test case:
> #include <cstdlib>
>
> #include "jni.h"
>
> void handleError(JNIEnv * env) {
>     if (env->ExceptionCheck()) {
>         env->ExceptionDescribe();
>         std::abort();
>     }
> }
>
> int main() {
>     JavaVM * vm;
>     JNIEnv * env;
>     JavaVMInitArgs args{JNI_VERSION_1_2, 0, nullptr, true};
>     if (JNI_CreateJavaVM(&vm, reinterpret_cast<void **>(&env), &args) != JNI_OK) {
>         std::abort();
>     }
>     auto const c1 = env->FindClass("java/lang/Class");
>     handleError(env);
>     auto const id = env->GetMethodID(c1, "newInstance", "()Ljava/lang/Object;");
>     handleError(env);
>     auto const c2 = env->FindClass("java/lang/Object");
>     handleError(env);
>     env->CallObjectMethod(c2, id);
>     handleError(env);
> }

Workaround:
> Call via JNI the suggested replacement of clazz.getDeclaredConstructor().newInstance() instead of the deprecated java.lang.Class.newInstance().

Change-Id: I85ff7102a18b98561f188e609873753546bc050d
Reviewed-on: https://gerrit.libreoffice.org/71240
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

... which was obviously omitted in commit
6b678c13, which introduced the correct
value of 0x0491 (1169) in addition to the pre-existing 0x043C (1084).
The new value is used when user sets relevant entry in Region and
Language control panel applet (intl.cpl); having the old value in MSI
summary information blocks auto-detection of proper installer language.

[MS-LCID] Appendix A mentions that the new code is available since Win7,
so we are good with the fix.

[MS-LCID] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9cCo-authored-by: Eike Rathke <erack@redhat.com>

Change-Id: Ic03b0e8eaf145c662fde48846cd5307e362d4d63
Reviewed-on: https://gerrit.libreoffice.org/71242Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

Had found

> sh: -c: line 0: syntax error near unexpected token `('
> sh: -c: line 0: `file /Users/stephan/Software/lo/core/instdir/LibreOffice.app/Contents/Frameworks/LibreOfficePython.framework/Versions/3.5/lib/python3.5/site-packages/setuptools/script (dev).tmpl'

in workdir/CustomTarget/instsetoo_native/install/install.phony.log on macOS.

Change-Id: I4b01b5f0a292424a60558cdb8b431a3d8dbdf1d4
Reviewed-on: https://gerrit.libreoffice.org/71234
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

re-arrange the conditions so we avoid the dynamic_cast most of the time.

This takes the file-open time from 40s to 29s for me.

Change-Id: If65a63502fd545003137747605332be65d5e91ca
Reviewed-on: https://gerrit.libreoffice.org/71229Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>