[Libreoffice-commits] core.git: vcl/unx

[Niklas Johansson]

 vcl/unx/gtk/a11y/atkaction.cxx |    6 ++++++
 1 file changed, 6 insertions(+)

New commits:
commit 04ab8aeb7a11205c0cf8cb26eb2395a43011435f
Author: Niklas Johansson <sleeping.pillow at gmail.com>
Date:   Sat Oct 3 00:02:51 2015 +0200

    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 <Samuel.Mehrbrodt at cib.de>
    Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt at cib.de>

diff --git a/vcl/unx/gtk/a11y/atkaction.cxx b/vcl/unx/gtk/a11y/atkaction.cxx
index 71f072f..7bdf932 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 ) ) );
+            }
         }
     }
 }