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

This way the type detection is guaranteed to receive the document service
name whenever a file is being opened from Calc.

Change-Id: I0eec06d4ca1f3f30bcbc5685af73392276990d69

This info will be used during type detection for more clever filter
selection.

Change-Id: I66a52ff6f425e97884afd1c85831c11381fb695d

Change-Id: Id6943713ade8a77f3f72aabf2e74635875cf5249

Change-Id: I96997da0eb038cab4bdba32e0d797747623f4853

This should reflect the fact that this type was already used as a
generic HTML type.

Change-Id: I0a209d51ed229f07aff001075c39bfc82d4c3088

Change-Id: I35a3efc506bbcc33ea4c3d2466929f8227dae102

Change-Id: Ie335ee44a347ab588dbf6cdeb38ef19246c1ad47

But it isn't needed here anyway, the "command line" is so short, so
just use lo-main-cmdline instead.

Change-Id: Icca1b57228584cee5962a33cd0d18873b13b2884

Change-Id: Icb84c34782dd41e0658f5f8ed4f689f149331d99

Change-Id: I9ed4df2a25c8a2a868f83de48472715a6cabe2be

Change-Id: Icaef88ba850f40e2354e896f688d11abba31fd8a

Simpler, and more light-weight now.

Change-Id: I1d512f92714b0836dc75a187024af263e208484f

Just a line at the top and the bottom, we do not want the entire 3D effect
here, it makes it visually incompatible with the window decorations.

Change-Id: I262932fb5def21d5bc4fb347be6d6a07807bb4d2

Change-Id: I9d118a5fbe2306465d8bcdb9ddd0596588137e5e

This makes both sw/qa/extras/ooxmltok/data/n705956-{1|2}.docx testcases
work at the same time. As far as I understand it, the .docx filter
calls into oox and at the end if gets the shape, while the shape
is removed from the ShapeContainer. In the case of recursion caused by
<w:pict><v:shape><w:txbxContent><w:pict><v:shape>, clearing the whole
list is wrong. Also, the OSL_ENSURE seems to suggest that there should
not be more than one shape inserted by each read. So simply consider
maShapes to be a stack when importing .docx .

Change-Id: I7263aeaf74c8d31a05e64c56b880cbc6b00d7dd6

Change-Id: Ie9a41292bd90919355991a187f17eb810dfc4dc1

This is pretty much a revert of 60cb70b9.
Turns out e.g. <v:shapetype> is not local only to its <w:pict>.
Added a testcase.

Change-Id: Ibbb9fe01bc2fc77dd67151bf4ca0905443eebf63

Change-Id: If97589c7b7ad647b22de229a6161b4fd78c757c8

Change-Id: Ifbb21fc26eedfde4afe2e3faf637346554f63d94

Change-Id: I00e1202de7bf5d20b4ac314dd138a3bb486245cb

Change-Id: I06dc09d57821ac729182764882558fa079b5ed37

Change-Id: Ia760fe7ae66f8caadb10947c3d743a9f64a55dc5