Enable pasting of LINK data from the system pasteboard on macOS

Also add more documentation on how the flavorMap array works. The
interesting thing is that the code stores anything you throw at it on
the system pasteboard. But in another LibreOffice process, it won't
accept types not mentioned in the array even if it as such is a type
that other parts of the code would look for.

Thus, adding the
"application/x-openoffice-link;windows_formatname=\"Link\"" type to
the array means that if there is such data on the system pasteboard
(from an earlier or simultaneous run of LibreOffice), it will be
pasteable also in a different LibreOffice process from the one that
put it there.

(While at it, order the FLAVOR_FOO variable definitions to be in the
same order as their use in the array entries.)

Change-Id: I913cc732e4dfb32d4b098505aa10806976db6326
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109384
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109472
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

1 files changed, 13 insertions, 2 deletions

diff --git a/vcl/osx/DataFlavorMapping.cxx b/vcl/osx/DataFlavorMapping.cxx
index 1c6eaac98a4d..41ef196e40a5 100644
--- a/vcl/osx/DataFlavorMapping.cxx
+++ b/vcl/osx/DataFlavorMapping.cxx
@@ -73,7 +73,6 @@ namespace
     return [NSString stringWithCString: utf8Str.getStr() encoding: NSUTF8StringEncoding];
   }
 
-  const char* FLAVOR_SODX = "application/x-openoffice-objectdescriptor-xml;windows_formatname=\"Star Object Descriptor (XML)\"";
   const char* FLAVOR_SESX = "application/x-openoffice-embed-source-xml;windows_formatname=\"Star Embed Source (XML)\"";
   const char* FLAVOR_SLSDX = "application/x-openoffice-linksrcdescriptor-xml;windows_formatname=\"Star Link Source Descriptor (XML)\"";
   const char* FLAVOR_ESX = "application/x-openoffice-embed-source-xml;windows_formatname=\"Star Embed Source (XML)\"";
@@ -83,7 +82,8 @@ namespace
   const char* FLAVOR_GDIMF = "application/x-openoffice-gdimetafile;windows_formatname=\"GDIMetaFile\"";
   const char* FLAVOR_WMF = "application/x-openoffice-wmf;windows_formatname=\"Image WMF\"";
   const char* FLAVOR_EMF = "application/x-openoffice-emf;windows_formatname=\"Image EMF\"";
-
+  const char* FLAVOR_SODX = "application/x-openoffice-objectdescriptor-xml;windows_formatname=\"Star Object Descriptor (XML)\"";
+  const char* FLAVOR_LINK = "application/x-openoffice-link;windows_formatname=\"Link\"";
   const char* FLAVOR_DUMMY_INTERNAL = "application/x-openoffice-internal";
 
   struct FlavorMap
@@ -94,6 +94,16 @@ namespace
     bool DataTypeOUString; // sequence<byte> otherwise
   };
 
+  // This is a list of the bidirectional mapping between (internal) MIME types and (system)
+  // pasteboard types.
+
+  // Only pasteboard types mentioned here will be recognized, mapped, and available for pasting in a
+  // fresh LibreOffice process. When copy-pasting in-process, the situation is different.
+
+  // Also MIME types not mentioned here will be stored on the pasteboard (using the same type name),
+  // though. But that is IMHO a bit pointless as they in general won't then be pasteable anyway in a
+  // new LibreOffice process. See the use of the maOfficeOnlyTypes array.
+
   // The SystemFlavor member is nil for the cases where there is no predefined pasteboard type UTI
   // and we use the internal MIME type (media type) also on the pasteboard. That is OK in macOS,
   // there is no requirement that the types are well-formed UTIs. It is different on iOS, I think,
@@ -127,6 +137,7 @@ SAL_WNODEPRECATED_DECLARATIONS_POP
       { nil, FLAVOR_WMF, "Windows MetaFile", false },
       { nil, FLAVOR_EMF, "Windows Enhanced MetaFile", false },
       { nil, FLAVOR_SODX, "Star Object Descriptor (XML)", false },
+      { nil, FLAVOR_LINK, "Dynamic Data Exchange (DDE link)", false },
       { nil, FLAVOR_DUMMY_INTERNAL, "internal data",false }
     };