Similarly to commit 697173f6, we have to
preserve the correct content-type which is not the same for PPTX and PPTM.

This commit also changes sdfilt.component to use the constructor feature.

Change-Id: I4b334540ec07a53d308e6b9dd6403294842bddf8
Reviewed-on: https://gerrit.libreoffice.org/40195Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Reviewed-on: https://gerrit.libreoffice.org/40265Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>

It works here because Date is ignored and only Time is returned, so just init
empty. The original value was a double date.time since null date.

Change-Id: If420769464860481416b0da172ddd2e17c13e641

And make some tools::Time conversion ctors explicit to catch more oddities like
automatic conversion from sal_Int64 that might be unintentional.

Change-Id: If275297d86d6657544c056a712b862523e310e44
Reviewed-on: https://gerrit.libreoffice.org/40275Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>

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

Change-Id: I2113f64bac9f1e7421416266d20004b35ddbc54b

Change-Id: I52780b012a1e5a382e2245fb1d857e64322bee4a

Change-Id: I486428da5459e758d23dd58b189b539896886c4c

Change-Id: I43f38b4dda6b1999d84d9f9760d0fae4c0358394
Reviewed-on: https://gerrit.libreoffice.org/40277Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I91d559596dcfbca603613bc4e9db7fe3348984c6

these are broken (from msgfmt's perspective anyway) already
in our translations and pootle warns about them

Change-Id: I9ce7c651273e334ecb92a592397886e2b95907da

Change-Id: I3a0a7620c9ed0aec438d149bee80c6979b0a3bd7

Change-Id: I9fe10986270117495628817b56ddf31f9f315454

Change-Id: I3d2a7bd97c085c68dc5036b6cb3731c24ed63aa2

Change-Id: I31f5a23e0f328273b8a165e58863b771853f3d3c

Change-Id: I675a29185c0401a8462ece17f70db82d188a53c5

Change-Id: Ie433614e074da0034ed532ed4569ef3648e48267

Change-Id: I81af71041d8d9d0074c9585ced510d7daab07c20

Change-Id: Ia0c00f6f978428d68b3c53051e26e1913b207dbe

Change-Id: I6b9492b3abb25bc546d672626d438cbd407c8c0f

during CppunitTest_sw_tiledrendering at least

Change-Id: I0de400443858926d7e2041934bbab61ade214c71

Clarifies code and gets rid of explicitly casting the operand to sal_Int32.

Also in preparation of removing DateTime::operator+=(sal_Int32) that is
confusingly similar to DateTime::operator+=(double) and just depends on type.

Change-Id: I83422e2940fbb017978db9b5734b4966228af3de
Reviewed-on: https://gerrit.libreoffice.org/40248Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

If the text box is removed, the SwFrameFormat of the drawing shape still
retains a pointer to the frame SwFrameFormat, and the latter is owned by
the SwUndoFlyBase.  This is pretty bad, so try to clear & reset the
connection between them in SwUndoFlyBase::InsFly() and DelFly().

Hopefully nothing will actually delete the drawing shape SwFrameFormat
while the Undo object is alive.

Note that when the SwUndoInsLayFormat is created when the text box is
added, the GetOtherTextBoxFormat() returns null as it's set later,
that's why the constructor can't do anything.

Change-Id: Iae562b6f8f272e47b2b5cf8ee80778db15d29ce0

Change-Id: I43d28a0957556900102cf87f024174d5c451a01d

Change-Id: I9ee596c7cde3d885f401447d6c10e7e30b958af7

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

Change-Id: I19c27e524d2ad1e57fa3ca41b1bfaed17215bd76

Change-Id: I6d380dde0214b41535e99798c24b19fe21e30772

Change-Id: Ied1f7a8c4135d3fd6a4581ea5e92f89b2e6b3067

Make sure they match.

Change-Id: Ib3ce948a29472281705e361792c924893ad97b32
Reviewed-on: https://gerrit.libreoffice.org/40259Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: Ia776d159aecc3082f46efe5bdd46477b45576b31

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

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

e.g.  helpid[s].hrc -> helpids.h
and insert include guards where missing

move "ordinary" defines into .hxx files

remove .hrc entries that are used as arguments to dialog factory
when a dedicated method can be added instead

Change-Id: I792fb8eb0adfaa63cf354e6e57401fc943e9196e

* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
  MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
  goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
  to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
  mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
  results in inserting the english original so something can be found, now the
  standard fallback of using the english original from the source key is used, so
  partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
   xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
   xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
   content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
      com::sun::star::resource::OfficeResourceLoader
      com::sun::star::resource::XResourceBundleLoader
      com::sun::star::resource::XResourceBundle
    when translating strings via uno apis
      com.sun.star.resource.StringResourceWithLocation
    can continue to be used

Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a

Explanation for each conversion:

- osl_acceptPipe()
    - don't worry about an invalid oslPipe sent as function parameter an
      error gets flagged in Unix normally, so it might not be a
      programming error
    - definitely assert on an empty name, that's a definite programming
      error and should never, ever occur
    - createPipeImpl() allocates and initializes memory for the
      oslPipeImpl structure, if it can't do this then something has been
      done wrongly

- osl_receivePipe()
    - invalid oslPipe sent as function parameter might not be a
      programming error, give a warning but don't assert

- osl_sendPipe()
    - invalid oslPipe sent as function parameter might not be a
      programming error, give a warning but don't assert

- osl_writePipe()
    - really just a thin wrapper around osl_sendPipe(), which detects
      and handles invalid pipes

- osl_readPipe()
    - really just a thin wrapper around osl_receivePipe(), which detects
      and handles invalid pipes

Change-Id: I4923265b4c648852743c406b682d43ffb9ac6537
Reviewed-on: https://gerrit.libreoffice.org/40003Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

There is an incomplete test of ::osl::Pipe::Pipe(oslPipe, __sal_NoAcquire),
but the comments show that the tester wasn't able to figure out a way to
test the noacquire variant of this constructor. However, they seem to
have not just given up but copied and pasted the acquire and no acquire
tests - the error codes for the acquire test talk about non-acquisition
and don't actually see if the handle is the same or not.

I have fixed this test. To test if the noacquire is working or not then
you merely have to:

1. create a new Pipe instance
2. create a new Pipe non-acquired instance copy of the first instance
3. delete the non-acquired instance copy
4. try to send a single character to the original Pipe instance, which
   should return an error (negative return result) because at this
   point there is no valid pipe to operate on as the pipe should have
   been destroyed when you deleted the copy.

If the send() succeeds, then this is a test failure.

For the acquire test, it didn't actually test if the handles are the
same - I have corrected this now.

Change-Id: If868746233d3a222cc6f9e7cd0d453e70ef6c7cc
Reviewed-on: https://gerrit.libreoffice.org/40102Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

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

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

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

Change-Id: I6610a986795c3169077b9c1a8e65a86f5488243d
Reviewed-on: https://gerrit.libreoffice.org/40230Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Akshay Deep <akshaydeepiitr@gmail.com>