If the outer if-block is entered, 'aIsCollection' is
returned, no matter whether the inner if-block
is entered or not.

Change-Id: Ief33e6fe6e29d1dfe287095424dac92e7f7d06b0
Reviewed-on: https://gerrit.libreoffice.org/13512Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: Ibcd2199db171c531018301631d76ec56924da23a
Reviewed-on: https://gerrit.libreoffice.org/13511Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

This addresses some cppcheck warnings.

Change-Id: I7e85aca5a86f993a9906525edffbd44a179dc245
Reviewed-on: https://gerrit.libreoffice.org/13510Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: If082f723383da72eac75ca660203aea2a33a7526

Change-Id: I7e6851ce3f24ef3c5051eb7431b6aa1df845836d

Change-Id: I3a429d0a6f771f6bfde2331ddc8544c92d8147f7

rather uglyish unittest, but still worth it as cutting nothing needing
to have sideeffects is really kind of non-obvious and prone to return

Change-Id: I02bbfb05f019874d873670cdae060ac3183f5ca6

Change-Id: I2ae917b43b18b14dce01121902a678d45ad520fe

Because VS Express has no native 64Bit compiler but a 64 Bit cross-
compiler. The path resolution to detect binaries and libraries was
not suitable for the cross compiler. The added resolution is only
effective if no native compiler was found.

Change-Id: I8066cb04f94eb4bfd0c57b35e5e39883c51ee046
Reviewed-on: https://gerrit.libreoffice.org/13515Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>

Change-Id: I4dbc69ca2618c37184ffdc217493e3880e149617

Change-Id: I0211c9c7dcc24ce40fe7c573f35ac13c02e742c1

Change-Id: Ifdfcbd9d3d62d2a55e3e050d4723700f8436e57a

Change-Id: I46e2de444d38f1f93eb68ffd50b7a283d05d1738

Changed behavior of right click context crop image from
bringing up dialog for crop (uno:GrafAttrCrop) to the
interactive crop (uno:Crop)

Change-Id: I98d01c39ad5baa894bb687e8adb3dced478d855c
Reviewed-on: https://gerrit.libreoffice.org/13472Reviewed-by: Yousuf Philips <philipz85@hotmail.com>
Tested-by: Yousuf Philips <philipz85@hotmail.com>

Change-Id: I81746860198864bb5917a6c1e898b742b65d77e1

There is still some duplication, as the file type -> resource mapping is
there two times.

Change-Id: I50cd58f1cc62e872fb925556dd151f6392eeeb87

Change-Id: I09049db51668176b90dabe2c82d525b2fab60299

...for cases where ? "a" : "bb" does not work, as well as to work around the
MSVC bug for cases like ? "a" : "b".

Change-Id: Id404716047aca5cc81440f291616d92365379b8f

...to use single ASCII character literals "more directly" in the OUString API
(instead of having to go via an intermediary OUString ctor call).  Especially
useful for character literals that are defined as const variables or via macros
("direct" uses of character literals in the OUString API can often simply be
replaced with single-character string literals, for improved readability).

(The functions overloaded for OUStringLiteral1 are those that are actually used
by the existing LO code; more could potentially be added.  The asymmetry in the
operator ==/!= parameter types is by design, though---writing code like

  'x' == s

is an abomination that shall not be abetted.)

Change-Id: Ic5264714be7439eed56b5dfca6ccaee277306f1f

Non-ASCII characters (like Unicode "é", represented as two bytes \xC3 \xA9 in
the UTF-8--encoded source file, and presumably passed trhough unchanged by
compilers into the resulting string literal object) in the OUString "literal"
ctor trigger a SAL_WARN_IF in rtl_uString_newFromLiteral, but are copied
"verbatim" into the resulting OUString, which will thus contain UTF-16 code
units \x00C3 \x00A9 (if char is unsigned) resp. \xFFC3 \xFFA9 (if char is
signed).

That assertXPathContent shall indeed match such an odd OUString value looks
suspiciously like a bug elsewhere, papered over by a broken test.  To be
investigated.

Change-Id: I07c995ad0e17235c214d7630fb34e8ef35d5ad30

Change-Id: I63f3954546e656d37ed6e22efd75b16df9fbcbac

Change-Id: I844c00639307c14140ba7e8a1b919e3f2ecdc114

Change-Id: Ib8f0f86a30342ca455a92c9add5b2836fa40f8f4

Change-Id: Iadc7b4d970e8c3b7f719ed6aab49986a1186cccb

Change-Id: I63e97e91792fcf2bf8758a1444bb29e3c1ccd541

Change-Id: I841b9b3f74a9822fe8c477a280bbe2f4904ed64c

start docked, move to undocked
start undocked, move to dock, back to undocked
start undocked, with and without size saved in settings and restored

Change-Id: I0bfdceb11aabdf9fdb855b97433b2af0532e4d03

Change-Id: I3efcac58f7a6629ae2615e29ea564e583414479c

Change-Id: I2633173bb21da554f55b244d6d2947567c933c2a

Change-Id: Iffdc04464bd70ca70684f28e6d6e23a054bfc8a7

Change-Id: I176a79bce85fa81310a53fcfecc6e0bc63f0ae18

Change-Id: I90375232aefbe40412614ca0f30ba467cf393f2e

Project: help  52ecb7b19fd337cad7809298849909493dff0c56

Change-Id: I0f5b4b1d5f5cf872555db77f07e68b2b980e3df1

Change-Id: I9923332372c1a09a734f3c6fd1bbd5989c6dc5d3

There were two inconsistencies here:

- The doc browser activity had an explicit android:theme, but the viewer
  does not, so remove it to be consistent, this fixes the about dialog's
  "black text on black background" problem.
- Now the doc browser had white text on white background: the about
  dialog explicitly uses android:textColor for the strings which should
  be readable on a bright background, do the same in
  file_explorer_folder_icon and file_explorer_grid_item, that makes doc
  browser text readable as well.

Change-Id: Iae9103556ca7c32c9ac8ea02d9e5d5fa6dfb72b5

Change-Id: I690163d7ab6d62c93da33d416e8757311f5d35c1

Change-Id: I310abed7e86f8b7153817be5ae03cc3c8fec3c50

Change-Id: I2806f35ee112b9ea7ccf323e01372f7e2f68ffa2

Low-res tiles should be handleded before normal tiles so for this
add priority to tiles and store in a with priority queue.

Change-Id: I8d36c14503d9b684816d99f577198ac34b729d15