One step closer to opening my simple test file correctly in Excel.

Change-Id: I1bfa76a46081ba478e44d8d90d8a91790a9a9ff3

The extra semi-colons were confusing clang. Just remove the macro,
it's not adding any real value.

Change-Id: I7f7c312d2c0167a17e31624e197ae75b77fa0c2f
Reviewed-on: https://gerrit.libreoffice.org/3677Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

...since 81af84c0 "gbuild: let JunitTests run
with MSVC."

Change-Id: I4ba97431c3439c0bed74149fe66cbb76db5317ce

Change-Id: I36c62fc677de70c08d0d59e45debc6a86375d3b7

...rather than a TypeDescriptionManager service that is no longer available.

Change-Id: I1054ab0a658597a60d11e2f9aa0960df25d14bc4

Change-Id: I7c750debaeee5d9804be378e0f65bec13ac296eb

Project: help  eddac30b5afa84c2420a553d2e822722dc857228

Let foo.odb be a database file that has a macro that connects to the
Database on "Open Document" event (and needs to prompt user for
user/password).

There was a race condition between two actions:

 1) the asynchronous treatment of "OnFirstControllerConnected" in dbaui::OApplicationController,
    which tries to get dbaui::OApplicationController's mutex

 2) the StarBasic macro calling dbaui::OApplicationController::connect
    which needs to display a dialog (to get username and password),
    and thus puts that dialog in the main thread's event queue
    and waits for it ... with dbaui::OApplicationController's mutex held

Now, if "1)" is before "2)" in the event queue of the the main thread,
*but* "1)" is executed *after* "2)" has taken the lock, there is a deadlock.

Fix:

 1) Make OnFirstControllerConnected synchronous.
    Make sure (by taking mutex in dbaui::OApplicationController::attachFrame, its ancestor in the call graph)
    that nothing else will happen with the OApplicationController as long as it is not finished.
    ---> it does not need to take mutex itself anymore

    This avoids the "order in the asynchronous events" dependency.

 2) Change dbaui::OApplicationController::ensureConnection to do the user prompting
    WITHOUT HOLDING the mutex, and use the mutex "only" to protect actually assigning
    the connection to m_xDataSourceConnection.

    Theoretically, in some race condition, we could connect twice and then discard one connection <shrug>.
    ensureConnection will never return the discarded connection, though.

    (I think I got that right with respect to http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)

    This keeps it from locking on another condition while holding the mutex.

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

Change-Id: I2555dc113b2fb4c77bec187b15f0bb545811b07b

Change-Id: I7a4f782235a23f50bceaef041a92e42e47860a78

Change-Id: I55447aba5abcc8205543c7ca64763b5c99854837

See the comment in climaker_app.cxx main about room for improvement.

Change-Id: I11cc2f62c9d42269d5c96253198ee4e730496e75

Change-Id: I2ff65979a9da7da12ad6ac97dc090898913a2e8c

Change-Id: I181c87f8406f095bd4dc499b47d91081f58aaf59

Project: help  7584ed08efd8e9cea733a782544a1e1eeb48433f

Build tools do not link against merged libraries but individual small
ones we need for this (gb_BUILD_HELPER_LIBS).

Change-Id: Ia765e11a93ed05d126334a3e146fb88e368954ac

Change-Id: I801f4af269efcea91bc3bafbfc9e0b9033488f2d
Reviewed-on: https://gerrit.libreoffice.org/3645Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: If6caa7abed25ce95f1c62f9673619426eb49b5a8

Change-Id: I47f1a72fac3e6678b5dfe880f2f189ffc436333b

IMHO there is no reason why they should be 0444. I have found no
explanation for it, either in the commit that introduced the bundled
dictionaries or in the related bug.

Change-Id: Ia42218a0d579ced5f17248a092eab2c61cb9005f

Change-Id: I3edbae98c9bb51899e5592fae1cfe9f3632ad535

It turned out that ApplyDXArray() is need to apply advance width
adjustments after justification, so we can't just bypass it.

So I just copied GenericSalLayout::ApplyDXArray() and stripped it of
ICUism so it does not break with HarfBuzz, but I had to make
m_GlyphItems non-private, so I'm not sure this is the right approach.

Change-Id: I66d647c3590fdf912c39d0cf23ac72bcc7ca72c9

The 3rd parameter to hb_buffer_add_utf() should be the length of the
whole text not the current run, so that HarfBuzz can take the context
into account when shaping.

Change-Id: I9e4e928d40078c3e3667cfdb6d8f24bf6e58263d

No more second guessing if text width, we know that information already,
so pass it around instead of trying to re-create it.

Change-Id: I19faacbc309d38753c3c9f7214dfa0bf59cc66b5

Not that I'm a fan of Hungarian notation, but for the sake of
consistency. Fix some placement of opening braces along the way.

Change-Id: Id6ea758fd438a4040e7451430a0f3a166efdec43

Change-Id: I78efebb576dffa8d39e98283feb9aab2186b5a39

GenericSalLayout::GetTextWidth() uses GlyphItem's mnNewWidth when
calculating text width, and though this seems logical (it is after all
the actual with the glyph is contributing to the all over advance
width), it results in shorter width calculation whenever glyph width
adjustment is involved, no idea why!

The #ifdef is there so that the ICU code path is not changed in anyway,
but all of this should be merged into GenericSalLayout when ICU is
gone.

Change-Id: I7cbde1675b78e87c142513eb52a13ee5fdc60617

Use local variables instead of altering the returned glyph positions
array, looks more cleaner this way.

Change-Id: Ibbcced57777010bd045668a99d7beb0618abe226

X and Y offsets should only affect the position of the current glyph,
not any subsequent ones.

Change-Id: I9dd1576cbdbb36b70f1898dc52702c02c4e851af

It turns out it is GenericSalLayout::ApplyDXArray() that is messing with
glyph advance widths trying to recalculate them. It is very old code (it
has been there since ICU were introduced back in 2002), but whatever
issue it is fixing, HarfBuzz does not need it.

Change-Id: I5c896d3f318e2f17d135f9eea599b917e04ed592

Change-Id: I7943c7e388b1cb73311d666ff600a31ac70c2838

Change-Id: I459f847a67282bd1e3dc914e25a39815a6e177a0

Change-Id: Id6c566ada50bd4d6f4043bbff25114e7872b7cc8

Project: help  0021ca3f232ca48538685fc75e70616d5e12c407

Change-Id: Ie8c3d30cb28afb97d4ded4ac67241ed18ab9e50c
Reviewed-on: https://gerrit.libreoffice.org/3651Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: Ia36b42be8f5caa93937e870467c95f47439d9c9e

Project: help  53c7b09224a3206cc72f65a4001b32e912ca5a45

Change-Id: I79c5b123abf671d51deadd56644271124420ce64

when you change the text direction it should update the numerical type but it dosen't.
this patch will get you out of edit mode before changing text direction and after finish the change it will get you in again

Change-Id: I5598fd9dab823c738a812537743695ec88690a24
Reviewed-on: https://gerrit.libreoffice.org/3629Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: I25140e854458186c7f66aba1baeabd5fadb3e162
Reviewed-on: https://gerrit.libreoffice.org/3655Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>