From 04ab8aeb7a11205c0cf8cb26eb2395a43011435f Mon Sep 17 00:00:00 2001 From: Niklas Johansson Date: Sat, 3 Oct 2015 00:02:51 +0200 Subject: Allow non ASCII chars as accelerator part 2 This is a follow up patch to the commit: b80be50268f534e215d36d69b93d3f51d9410ace This takes care of exposing non ascii characters to atk so that the orca screen reader has a chance to present these characters to it's users. I was considering removing the KeyCode bits all toghether and rely on what we get from KeyChar but got cold feet in the end. Change-Id: I7a3e78c47b81f8b36763c56e0298e8bbf226dccf Reviewed-on: https://gerrit.libreoffice.org/19105 Reviewed-by: Samuel Mehrbrodt Tested-by: Samuel Mehrbrodt --- vcl/unx/gtk/a11y/atkaction.cxx | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'vcl/unx') diff --git a/vcl/unx/gtk/a11y/atkaction.cxx b/vcl/unx/gtk/a11y/atkaction.cxx index 71f072f2fabe..7bdf93206c63 100644 --- a/vcl/unx/gtk/a11y/atkaction.cxx +++ b/vcl/unx/gtk/a11y/atkaction.cxx @@ -203,6 +203,12 @@ appendKeyStrokes(OStringBuffer& rBuffer, const uno::Sequence< awt::KeyStroke >& if( c != '\0' ) rBuffer.append( c ); + else + { + // The KeyCode approach did not work, probably a non ascii character + // let's hope that there is a character given in KeyChar. + rBuffer.append( OUStringToGChar( OUString( rKeyStrokes[i].KeyChar ) ) ); + } } } } -- cgit