Change-Id: I1871e5e3a319b2d5177ae4bd470046c022c14eb7
Reviewed-on: https://gerrit.libreoffice.org/3121Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Change-Id: I7db719ab118ff1003594bc481e11a5dbf7946b57

Change-Id: I7b3fb6f5c8b4dfed5ff225edecfe41d85a6f621d

Change-Id: I947709235e714a208eff6b57a7eba2f7dd386893

Change-Id: I98d8c5982b42b2f3283c50cf1da11331040ab884

Change-Id: I5b11f1bb94841b08fd82da31ff348ffca4c487c6

If all the libraries in a pagein file are already covered
by the libmerged in Pagein_common, create a empty file
to avoid a build error.

Change-Id: I05adcca6262ec9b6af33e3d2b9d26f4886640a43

Change-Id: I17593ac6e495213a1ef99d4d5525a6e38aee0bc7

Change-Id: I4397575e4665e8a257d0bd3e15245d996a48a1f4

Change-Id: I2e0459426323555ca78ed38c0749690269fdc3d1

Change-Id: I2d520b88927c6acb3d248da05815822315bd066f

Change-Id: I272c2efc21f78dbd35c6dff6143c4770aed4ec16

Change-Id: I7172436c6fea867cdb7a8f8d97b215efcd0a1ab5

Change-Id: Ib4c9cf4406683a2d298967dbff8e084cbd9a7b4c

+ convert while loops into for loops

Change-Id: Icb01b55d2932193f83344bda8c69c9a9954f6de0

Change-Id: I6cd97ea5056596122a8ae6cb0c5cd6525ce6b302

Change-Id: I93de737265651a47a2ed0a56bca27bd19a5c5770

+ convert some while loops in for loops

Change-Id: Ia68ce1b6297ad061233e56be2abf5b6ea98d3ddd

Readd removed SaveShapeAsGraphic to GraphicHelper with which it
is possible to export any shape to vector/raster graphic.
Additionally cleanup GraphicHelper and ExternalEdit (convertsion
to OUString, remove unused imports, comments).

Change-Id: I1af45e2ed5d3b66dbd80a5f3a71c44530e46baef

+ convert while loop into for loop

To check:
could we use std::find (find_if)?
Is it always ok to do begin()+1?
What about if we return aEnd?

Change-Id: I59107de5693ad7b37e5eef80134c34a03982151e

+ convert while loop in for loop

Change-Id: I615e2c724481047b557a4da9bb0753ec6eaecb90

Change-Id: Ibf5004c1e66edac10ec6392577fe26ea2aaed330

+ convert while loop into for loop

Change-Id: I64c2379c28d3c1074ed17129152568371680db19

Change-Id: I1c0d5ca4b2f88ca48225fcdbeb978f27fa91f7a6
Reviewed-on: https://gerrit.libreoffice.org/2953Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Peter Foley <pefoley2@verizon.net>

I am not really satisfied yet with how the UI redrawing in the app now
works (during startup, which of course is more or less all the app
does so far).

It can take quite some time before a "link" (function to be called)
posted with PostUserEvent() gets run (if there are lots of
time-consuming other "user events" in the queue already, or
something?), and blocking the UI thread for that time is not
acceptable. Will have to come up with some more complicated solution.

Change-Id: Icab20183df3bc4980ae33f0502d10397802cc391

Change-Id: I663ab56faf8d13a3f0443706d9dc75bd5969aece

We used to render them in the app main (GUI) thread, which is
dangerous, accessing the headless frames in one thread while the LO
thread (where the "main" LibreOffice code is running) might be
updating and changing them.

This fixes some problems like that part of the document did not show
up. If I would test the app on a multi-core iPad, presumably I would
have seen even more problems.

But this also introduces new problems: Now the UI doesn't appear
incrementally (for instance, with an actually progressing progress bar
during the loading of the document) as it used to. Now it all appeads
all of a sudden, everything at once. Which would be fine if it
happened very quickly after starting the app, but it doesn't... on the
original iPad it takes half a minute.

Change-Id: I04068e0d884aa5cb86acefa76449aac4e081b193

Change-Id: I6873461aed7db7b7f06e45556eacb82bcf118aea

Change-Id: Idd44c792b4e0ee9cd27c3d66c2c5d794f4304045

Change-Id: I5c2e05feecffa1679930b041854b1cd190ef007a

Change-Id: I9d16929d3b8fb5114e72eee850da64433394df9c

Much faster. No need for the pixelBuffer inbetween.

Change-Id: I6493faca6da3a3e9a1285e00c887928b85dca56e

Change-Id: Ia5e84bc661d0de1140a259be7dd9fcdaca5e1930

No, it isn't any closer to being "ready" despite the name, but still,
using the current approach, it clearly isn't restricted to be just a
viewer.

Also drop the verbose LOViewer prefix from class and file names in it.

Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c

Change-Id: If7245ceea45a517084fdb5df09818e4e6e8c8be5

Change-Id: I635be54c27c93de0a11be7bdd01979b99dadda28

Change-Id: I4c839e7b20e276b2fb3be60925de42ae91f47ee1

Change-Id: Icb72b18785bb37457f2eaf86e0639cedc119ee92

Change-Id: I2e216493168e5fea170fa9f0be35919a8c7d2020
Reviewed-on: https://gerrit.libreoffice.org/3101Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>