CMimeContentType::m_ParameterMap isn't modified after construction

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

...that had accidentally not been removed along with the definitions in
b75e3ded "tdf#120158: Base CMimeContentType on
INetMIME::scanContentType"

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

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

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

Change-Id: Ibe9a09dae281ea1bcd1da17bfaa9dfef051ddab8
Reviewed-on: https://gerrit.libreoffice.org/61692
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

fields are internal bookmarks. When the exporter runs
through the bookmarks, it will already write out a bookmark
entry, so don't output a separate one for the fieldmark.

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

Although this follows a very different code path, copy the ww8
import idea of "consuming" the bookmark of a BOOK_FIELD.

This is particularly important for textcontrols, especially
since LO keeps duplicating bookmarks as it adds another
bookmark for the field name at each save.

Existing unit tests that this matches are fdo53985.docx and
tdf111964.docx. I expected more, but apparently most fields
don't contain or represent any bookmarks.

This patch is for import only. A followup patch stops
the creation of duplicate bookmarks during export.

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

Optimize row height: Adjust the height of the selected rows
to match the height of the tallest row in the selection
(fit to content), without shrinking the table.

(Optimize rows is a new feature for Draw. My initial
implementation was replaced by setMinimalRowHeight.
This option is now the same as minimizing row height and then
distributing rows evenly except that it adds the benefit of
preventing the table from shrinking.)

Distribute rows evenly: Adjusts the height of the selected rows
to match the height of the tallest row in the selection
(regardless of the content), causing the table to grow.

(Previously, Distribute rows worked like Optimize now does,
but the documentation indicates that it should work this way.)

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

Optimize column width: Adjusts the width of the
selected columns to fit the entire column's content,
without changing the width of the table.
Any leftover space is distributed proportionately,
with thin columns growing slightly,
and wide columns growing much wider.

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

Now that we make sure UserInstallation/user directory exists, a
"backup" directory will be created there, and the edited document's
backup file placed in it, and not beside the original document
location (which wouldn't work on iOS).

Change-Id: Ibc0a6e7f0b596cc3d02774878cd8c3d53fda0c3e

Don't bother with a 'userinstallation' subdirectory. It is a
subdirectory called "user" of the UserInstallation value that will be
used for our stuff anyway.

Change-Id: Idb6b5992bfda73ed7af80274b0de8ad7b43c241c

If it doesn't exist lots of things go very badly. Took a while for me
to understand the mechanism, sigh.

Change-Id: I40300587a5f422876cbda68c5aa98a23ed707135

Context menu of a chart is supposed to be the same as for
other ole objects, except the additional .uno:ExportAsGraphic.
Given that .uno:ExportAsGraphic is hidden when non-chart
object is selected, we can just place it in the regular ole
object popupmenu (done already), and use that menu also for
charts.

Discussion is in https://gerrit.libreoffice.org/60128 .

Change-Id: I8a07c550998e1db0d2af7f87c625dbd258454bdd
Reviewed-on: https://gerrit.libreoffice.org/61678
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>

Change-Id: I12f7ebf8cb40c5c1ea40509ac38ae977e1abca89
Reviewed-on: https://gerrit.libreoffice.org/61677
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>

The preceeding mouse button down event could happen in a different (closing)
window, like context menu.

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

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

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

Now it should be fairly close to the (IMHO) ideal: One
SAL_INFO("sal.file") per file system system call. (Not read() and
write().)

Sure, on Linux one could just use strace, but my interest at the
moment is debugging what goes on on iOS.

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

Change-Id: Ie6545844546dc78d14e1fabdf28f4e1938cf2dd3
Reviewed-on: https://gerrit.libreoffice.org/61642Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Jenkins

Change-Id: Icb25fd00296f0584fdd503ad0e840870f8bc6774

across runs

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

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

This reverts commit 40e22f1e.  See the commit
message of <https://gerrit.libreoffice.org/61684> "tdf#120158: Base
CMimeContentType on INetMIME::scanContentType" why that change is considered a
superior fix compared to the reverted one.

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

...instead of using yet another local implementation of parsing media types.

CMimeContentType is the implementation of the UNO
css.datatransfer.XMimeContentType interface.  One observable change in behavior
is that type, subtype, and parameter names will now always be reported in lower
case instead of with the casing from the input preserved (but those differences
in casing are functionally equivalent per the media type specification).  Also,
parameter names supplied to the hasParameter and getParameterValue functions are
now also treated case-insensitive.

The upside of this change is that INetMIME::scanContentType (via "The encoding
of rMediaType should be US-ASCII, but any Unicode values in the range U+0080..
U+FFFF are interpreted 'as appropriate.'") already implicitly supports RFC 6532
"Internationalized Email Headers" extensions for media types, allowing quoted-
string parameter values to contain non-ASCII Unicode characters.

That means that tfd#120158 "Impossible to paste special in Writer from Calc in
Libreoffice 6.1.x in some UI languages - the dialogue caption says 'unknown
source'" can be fixed by just allowing non-ASCII typename parameters being
generated in ImplGetParameterString in svtools/source/misc/transfer.cxx, and
reverting the problematic (see the comments there) previous fix
<https://gerrit.libreoffice.org/61601> "tdf#120158: fix ImplGetParameterString
for typename".  (Which will be done in a follow-up commit, to ease potential
backporting, as that previous fix has already been backported to some versions
but not to others.)

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

It belongs in an autogen.input, not in a distro-configs file.

Change-Id: I2e22f94fe9e11986fa40a632e12a272193172bac

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

Change-Id: Ia42daaf0dbb8fcd0230c7cee21a0f5d560885c22

Change-Id: I9ff0b4287c5be0dfc83740b75d58cab78dc990f7

Keep sal.file for the SAL_INFO logging of file system calls (open,
close, rename, etc), and use sal.fileio for the (very verbose) file
I/O.

Change-Id: I0e166d83e20921696a8a0880f9fcbbdec55053dd

Change-Id: Idb7b16a6976df62a1beea8a01c812206a0b8b85a

Change-Id: Id18bafaaf8f5315a0590687d98ea97952bdf883b

The code is much too convoluted for my little brain. We can't create a
backup copy of a file from outside the sandbox in the same folder as
the original file. At least not using just normal Unix APIs. And if we
store it somewhere else, how would the user find it anyway? Let's just
skipt this mess for now.

No idea how the code manages to create backup files in the same folder
as the actual document in a sandboxed LibreOffice on macOS. Or does
it? Maybe we do some similar bypassing of the backup dance at some
other place in the code already, and I should just have made that
happen for iOS, too?

Change-Id: I0c90edf9e72f54cce78b2cd325e67c710b6df745

Change-Id: I4bea64f959a6d6f3010809261804748b4fcd7718

Change-Id: I03efe36dac946dd00c91af44a2f6401d56c23214
Reviewed-on: https://gerrit.libreoffice.org/61630
Tested-by: Jenkins
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

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

a) SetFirst doesn't imply SetMin
b) ModifyFlag and SaveValue are orthogonal

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

That folder typically is not inside the app sandbox, and the process
has access only to the one file that they have selected for editing
there. Trying to create other files in that folder is doomed to fail.

Change-Id: Ib4ff5c7c60aa372eb412e87dc8bbce48ec6d6b54

Change-Id: I66c3fb02f4c44adec5c8f663d8845658adfe803f

Change-Id: I1fde453d5d37481aedec152a1a4da8a85fc6c99b

Calling stat() on a non-existent file outside the sandbox fails with
EPERM on iOS, not ENOENT. (Presumably calling stat() even on an
existing file, but one you don't have been granted access to, also
fails, because that is after all a point of sandboxing, you shouldn't
even be allowed to figure out whether arbitrary files exist outside
the sandbox.)

Not sure why this change hasn't been necessary also for a sandboxed
LibreOffice on macOS.

Change-Id: I67c768e9c34fd17fa35f08232284210ff4a71b98