Non ASCII characters like åäö can be used as accelerator keys (Alt+<x>).
This already works however at the moment it is not exposed properly
to accessibility tools such as screen readers. After this patch at least
NVDA gets information about accelerator keys that are non ascii. On
Linux we need to adapt code in vcl/unx/atk/a11y/atkaction.cxx.

There is also vcl/source/window/dlgctrl.cxx#Window::GetActivationKey
should probably have similar treatment and I guess that it is related
to accelerator keys in dialogs but I need to confirm that.
I'm a bit unsure how to best do that so I'll save it for later.

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

Change-Id: I2dd58060c1f3c9f12356c4ab18a0c838e7cdd718

Change-Id: Ic1c5be7794ff374c32a3c727d6233f69ea38c7aa

Change-Id: Ic9023640c34c3d7efd00e2eb0894ed4d01109d8d

Change-Id: Ia8c080ef50e1ddbfce17b5c5d357a240edea46f2

Impress has tools Color that is wrapped in this primitive, then later
drawinglayer::processor2d::VclPixelProcessor2D::processBasePrimitive2D()
converts it back to tools Color. Problem is that the primitive uses basegfx
BColor, so the alpha channel is lost.

Add member and API to survive this roundtrip.

Change-Id: I940e60f6e352022306abac3223636d19dd859355

Change-Id: I9ca369fb5dcb4210db6740eac577e9144b288005

Change-Id: Idbeadeaebf85c9de84d6fafe4d140c77907c0eeb

Change-Id: I87922fb64dda54f245954d6c5eb3b244812ceaf0

...which broke all the stock /bin shells to no longer pass through any DYLD_*
environment variables, so the DYLD_LIBRARY_PATH passed into the firebird Make
would not be passed to all the places that need it (to find the external/icu
libraries that some executables link against which are built and run as part of
building firebird).

What works with two little tweaks is to build your own bash and pass it to make
with SHELL=...:

* For one, there is an empbuild executable that uses system(...) to call another
  isql executable, where the latter needs DYLD_LIBRARY_PATH set, but which would
  not pass through the system(...) call (which implicityl uses /bin/sh).

* For another, it is still necessary to invoke Firebird's make with an explicit
  SHELL=$(SHELL), for reasons that are not entirely clear to me.  (There are
  some Makefile.in in Firebird's extern/ sub-tree that set "SHELL = @SHELL@" to
  configure's CONFIG_SHELL, unless overriden via an explicit command line
  arguemnt, but I don't think those are relevant here.)

Change-Id: I1e68faa898e758f09efb602d96fd6b35657e0480

When replacing a selection with an autocorrect character
(like space, *, _) in Writer, the undo/redo remark
was "Insert $1" on Linux/Mac.

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

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

Change-Id: I69dfd6747e37ddb1727dd41b99d1b70eaed83425

Change-Id: Iabdb057fb2dc05cfb8c98864dc5109360b50633a

revert xmloff portion of

commit 35e68754
Author: Noel Grandin <noel@peralex.com>
Date:   Thu Oct 1 15:10:56 2015 +0200

    loplugin:unusedmethods

    Change-Id: I3d6f1300f4fae2af9e580d1d3b2c2c80fa9e9268
    Reviewed-on: https://gerrit.libreoffice.org/19075Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: I24aa3f113a77d93c789b063b3c099bf2038e1dad

Was not liked.

This reverts commit e4ddba2b.
This reverts commit ab092bdc.

Change-Id: If2e9e032a135530da92b5bd166f5b559b10b0b91

...this is a follow-up to efad388f "Clean up
Make SHELL handling," which broke out-of-tree builds.

There appears to be no good reason at all to fiddle with Make's own behavior of
determining its SHELL variable (which defaults to /bin/sh and can be overridden
via a SHELL=... command line argument when invoking Make).  The SHELL_BASH
fiddling in configure.ac and Makefile.in was probably cargo cult carried along
ever since 815f157c "CWS-TOOLING: integrate CWS
configuretoplevel," in a time when the OOo build system still defaulted to tcsh.

Change-Id: If906164abb6aae649ce8088d945a40213deed361
Reviewed-on: https://gerrit.libreoffice.org/19093Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I9b8d67540f646e7da59e35303bf75cc43367f2c3
Reviewed-on: https://gerrit.libreoffice.org/19092Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

* In configure.ac, honour a preset SHELL_BASH when determining SHELL_BASH (so it
  can be passed in via autogen.input).

* For both toplevel "make" and per-module "cd $module && make", consistenly use
  the SHELL_BASH determined in configure.ac as the Make SHELL.  (By moving the
  setting to a new, common soleng/gbuild/shell.mk.  This also exports SHELL as
  an environment variable to sub-processes now; this exporting can probably be
  reverted if it is not what is actually wanted---but note that this exporting
  of an environment variable to sub-processes is unrelated to how nested
  invocations of $(MAKE) obtain their Make SHELL setting, see below.)

* Remove the gb_SHELL override feature from solenv/gbuild/gbuild.mk; for one, it
  is unclear how it was intended to interact with setting SHELL=@SHELL_BASH@ in
  the toplevel Makefile; for another, overriding SHELL can be done globally via
  setting SHELL_BASH in autogen.input now.

* Make treats SHELL specially, in that it never uses the SHELL environment
  variable to determine the Make SHELL variable.  Instead, if this Make
  invocation, or any outer Make invocation it is nested in via calls of $(MAKE),
  was called with a SHELL=... command line argument, then that value is used
  (and otherwise the default is hardwired as /bin/sh).  So, when calling nested
  invocations of $(MAKE) from the toplevel Makefile, pass down the current SHELL
  value via a SHELL=... command line argument via GMAKE_OPTIONS.  (And further
  nested invocations of $(MAKE) will then automatically inherit the SHELL value
  given on the outer invocation's command line.)

Change-Id: I67fa1b88e4e90d09456c1fcad2d082fdce3c019b

Change-Id: I776c517ba87838c0c3391f79010a30fa7fe2abd3
Reviewed-on: https://gerrit.libreoffice.org/18939Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Change-Id: I51ed2ccb06ba4ced15cd0b8e23e59a9609f07e93
Reviewed-on: https://gerrit.libreoffice.org/18961Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Which happens e.g. during rendering tiles:
OutputDevice::BlendBitmapWithAlpha() produces an RGB alpha
(255,255,255), then tries to set a pixel in the 8bit alpha channel using
it, so when BitmapReadAccess::SetPixelFor_8BIT_PAL() tries to get the
color index, we try to get it from a color that is not indexed.

Let's assume that when the color is not indexed, it's always gray, so it
doesn't matter what color we pick for the alpha mask needs.

Change-Id: I325c1d70514fd176fdc9cc39683b444447adf07f

after commit 837f1718
"loplugin:unusedmethods in vcl"

Change-Id: Idd4603f34891950940a77efa30b9ee70f35d7533

...after 837f1718 "loplugin:unusedmethods in
vcl"

Change-Id: I43ade93c47d7633a5b660ae25fe1137df161cec3

Change-Id: I1bbf4ee7c67d40ffc7b289e0d75e4aed224067ec

that's just a local toy for now, didn't intended to push that

This reverts commit 4afbd029.

Change-Id: I20b758d4582022ffda35c4aed7251948e721f821

Change-Id: I648ad2fe4b4cd425b2f7f1014c063169beae54db

Change-Id: Ib10dccec244f3168f1ac4a892a09012adf38a839

...after d68a0fc0 "loplugin:unusedmethods"

Change-Id: If167025b7892738cbbbefd5fe4966a5e6aee57f3

Change-Id: Ib30f4e5f16518cbbe71cf03998513ebd8c2a4d1a
Reviewed-on: https://gerrit.libreoffice.org/18949Reviewed-by: Oliver Specht <oliver.specht@cib.de>
Tested-by: Oliver Specht <oliver.specht@cib.de>

after commit 837f1718
"loplugin:unusedmethods in vcl"

Change-Id: Ic0ece310202ecd1663d8933b10a6aef8b462a02d

Change-Id: Ia06d96d373888ce45508814c9752d09117e55d10

Change-Id: I5767fa9a240b23de098fc6012555691dfb22c400

Change-Id: I23bdc9a885228848568ebaf3fb618826598b8267

Change-Id: I3d6f1300f4fae2af9e580d1d3b2c2c80fa9e9268
Reviewed-on: https://gerrit.libreoffice.org/19075Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: Ib404310761fd555b033ab6594ba8636d37f23463
Reviewed-on: https://gerrit.libreoffice.org/19074Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

...where firebird's replacements of global new/delete would still be called for
"new" but not for "delete".  Lets hope that always adding the C++14 size_t
overloads of operator delete is harmless in all relevant pre-C++14 environments,
and only causes harmless warnings like -Wimplicit-exception-spec-mismatch in all
relevant C++14 environments.

(But why does a /library/ replace global new/delete in the first place?)

Change-Id: Ib0b0ad748c6641c07ffed6cec3d6809a1530679f
Reviewed-on: https://gerrit.libreoffice.org/19081Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

This just forces wget to use ipv4 when downloading
more context here:
http://lists.freedesktop.org/archives/libreoffice/2015-October/070412.html

Change-Id: Id7e6a2ccd2301aa0fd1456d20309fe4936b4a20b
Reviewed-on: https://gerrit.libreoffice.org/19090Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

So, do not bother to extend its children array.

Change-Id: I9550501469aec5c4420f127ab64003c5ab14f9c1
Reviewed-on: https://gerrit.libreoffice.org/19089Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: Ie1603adf3908fd0668bcbe8f75c6bafa0d0bfd6c
Reviewed-on: https://gerrit.libreoffice.org/19072Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>