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

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

Change-Id: Ie2159d5eb8caf3d8f13d9c1ec49cc2bb6a0d94eb

Change-Id: I4824395653052486956572cedf3b56b94f9df39e

Change-Id: I23fc6bf62e74f192f77c74ed48d5276737375f3c

Change-Id: I2fb3bd758d7b903cd148f847c21c0eefd6f091e5

Change-Id: Ic6771c4ae12686580301e114fa5aec7f7d4dc9a8

Change-Id: I39c301a98854d19e849a9e06ffac0657408456fe

_PC_NAME_MAX is a symbolic constant meant to be used as a pathconf()
argument, not a buffer length.

See also 2cd4e55b

Change-Id: I94d19bd6f9f0ae501329d6a1edecad630f44b356

_PC_NAME_MAX is a symbolic constant meant to be used as a pathconf()
argument, not a buffer length.

This piece of code was even "honored" in
http://womble.decadent.org.uk/readdir_r-advisory.html
"The code that enumerates fonts and plugins in the appropriate
directories uses a stack buffer of type long[sizeof(struct dirent) +
_PC_NAME_MAX + 1]. I can only assume this is the result of a programmer
cutting his crack with aluminium filings."

Thanks to Heiner Rechtien for pointing this out.

Note: declaring the buffer of type long instead of char looks weird but
probably has the reason that it is casted to struct dirent* for the
readdir_r() call that might not work on architectures that forbid
arbitrary alignment on non-even boundaries.

Change-Id: Ie959b8905d1328c6fcaefbf6f6c915cc430e85b6

Change-Id: I067d52236b189e09955d7aa3ce2fbd25b0d330bd

Change-Id: I2ff581a72aa66bff8943d31499013b31e360333b

Change-Id: I4196e763e8374d1f50700c20362245224acb9e13

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