Change-Id: Ib37f1fc9658cb50227463cf2aa1421ba47b2ec9f

Change-Id: I862b728537e9e862f1d5af78bcc87576964534d0

Change-Id: I51b86a10caa5da6e12583c2b22404b0d9282b13d

Change-Id: I12884e58505d94b76eb0ad955815ae1702716f0f

Change-Id: I862a4223c955c3a9e9a366b0f3a85465f38e76be

Change-Id: Ib60a2a4f0d28a53d997731eb34b118cc9b9f822d

Change-Id: I241be2704a069ec1f6be5861084039569673cc12

Change-Id: I872987e02c1685810f6c2c71956c60e5f13b2706

Change-Id: Ifb1d1e712c6fadc549dd7717ae1fae0fadcba9fa

.uno:OpenFromWriter
.uno:OpenFromCalc

Change-Id: I724570c6c291f83db930e2d118cc356a934352f8

Change-Id: Ie18c69615fed6020efe577d81bd905e2f3bcba31

Change-Id: If4b946ef4407279f3b260a0f8a8d8309522aa594

This already didn't work in 3.5.

Change-Id: I12afc1bcdc5c20a7846833763080dac02214e01b

Change-Id: Iaf4bd3e2c5f54f2c75ecba444f3122dd4ed126d0

AFAICS it appears that theres a one to one mapping from a SwFrameControl to
a SwFrm, so in any of the three given classes of Page, Footer or Header a
SwFrm will have zero or one SwFrameControls and a SwFrameControl doesn't
get rebound to a different SwFrm or anything like that, so we can use
a map and index off the SwFrm* to find them rather than constantly
looping over vectors to find the right one.

Maybe could move the SwFrameControl directly in the SwPageFrm's
themselves.

Change-Id: I1194f3cdcab747b61c645003c97e651f47f2bc09

Change-Id: Ie4a2f7c2d5943d01d971611209fc641412e82aa4

To use the app specific open command instead of the global open.

Change-Id: I86d20e1a412f6020fa2db79040e4e66b39e8c355

This is similar to what I did earlier for calc.  This info will be
used later in the type detection code.

Change-Id: I7ba7dcdc03cbfe77eba5c7594fc0385ad3775541

 - the original problem can be reproduced by creating new empty presentation in powerpoint.
   after it is loaded in impress, it was completely blank, without placeholder shape
   texts (Click to add title, Click to add text)

Change-Id: I541554e273372ad09cca2fb91e27a17eb1f3a00e

Remove now redundant FONTCONFIG cmdline arguments, and add fallbacks
for not having cmdline arguments in the intent when launching.

Change-Id: Ia88d892dea3d597215876a860a0f748f2ed6839b

Change-Id: I0f025114af5f79f5bd04637ffdf864cef75eb821

This is almost a revert of e05e77f4.
It turns out FindRealSdrObject() is mostly the right method to call
(possibly except when creating the document, which is what lead
to the first commit).

Change-Id: Iea9ccc99e785fbff47f2d41187326d4e6d355494

Change-Id: I4180b4d291b7a4ed496c7c57ca0fd0034dc2ed94

Change-Id: Iaf9a750860b4e51f576c37dab2d4844c2e2146cd

Change-Id: I08897ea5527e7ac56b37855b740a3dc1c8ddb544

Change-Id: I33ffca788182cd24d148614ee03c5a884baccf84

Still not perfect, the ideal would a 7x7 icon; but at least something.

Change-Id: I383921436db49c894fd336cb30c5fb9a3d4979a1

Change-Id: I09d0c5d6797b6df9e84ad3574fc420241fe72707

Change-Id: I49986d6feac5e46c7b2f3017cf97b07dce4db42f

Idea by Mirek M. - thank you!  Additionally introduced a tooltip showing more
verbose text when in overwrite mode.

Change-Id: I1236253bc6c97809ebed872fe86233cc08f41345

this avoid the root cause of this bug, avoiding creating a
B2DPlygon which contains no points.

It seems the code relies somehow on an null B2DPolyPolygon, hence the
change done here. Better would be to have time to look how to remove
this fact. But currently it seems the code relies on  a
rSet.Put( XLineStartItem( aArrowName, aPolyPoly) where aPolyPoly is
not defined in certain cases.

Change-Id: I61b75d925090d1c9a0da96ce1a6eea50a2d60e5a

This is a follow up to d015384e "Fixed
ThreadPool (and dependent ORequestThread) life cycle" that still had some
problems:

* First, if Bridge::terminate was first entered from the reader or writer
thread, it would not join on that thread, so that thread could still be running
during exit.

That has been addressed by giving Bridge::dispose new semantics:  It waits until
both Bridge::terminate has completed (even if that was called from a different
thread) and all spawned threads (reader, writer, ORequestThread workers) have
been joined.  (This implies that Bridge::dispose must not be called from such a
thread, to avoid deadlock.)

* Second, if Bridge::terminate was first entered from an ORequestThread, the
call to uno_threadpool_dispose(0) to join on all such worker threads could
deadlock.

That has been addressed by making the last call to uno_threadpool_destroy wait
to join on all worker threads, and by calling uno_threadpool_destroy only from
the final Bridge::terminate (from Bridge::dispose), to avoid deadlock.  (The
special semantics of uno_threadpool_dispose(0) are no longer needed and have
been removed, as they conflicted with the fix for the third problem below.)

* Third, once uno_threadpool_destroy had called uno_threadpool_dispose(0), the
ThreadAdmin singleton had been disposed, so no new remote bridges could
successfully be created afterwards.

That has been addressed by making ThreadAdmin a member of ThreadPool, and making
(only) those uno_ThreadPool handles with overlapping life spans share one
ThreadPool instance (which thus is no longer a singleton, either).
Additionally, ORequestThread has been made more robust (in the style of
salhelper::Thread) to avoid races.

Change-Id: I2cbd1b3f9aecc1bf4649e482d2c22b33b471788f