https://bugs.documentfoundation.org/show_bug.cgi?id=100443
--- Comment #4 from Charles Lindsey <c...@clerew.man.ac.uk> ---
OK, I think I have cracked it. I took your advice and consulted the people on
the #libreoffice-dev IRC channel, and they pointed me at gtksalframe.cxx.
But first some history:
In the beginning, there was X-Windows, which introduced an initial set of
keysyms (see keysym.h and keysymdef.h).
Then various vendors (DEC, Apollo, HP, Sun) added new keys to their products,
and invented new keysyms to go with them, with numbers of the form
0x1000xxxx see DECkeysym.h, ap_keysym.h and HPkeysym.h
0x1004xxxx see HPkeysym.h (which includes also OSF_Keysyms)
0x1005xxxx see Sunkeysym.h
all totally incompatible (for example, there are three versions of
Copy/Cut/Paste in there)
Finally, XFree86 invented a grand new list to encompass the lot:
0x1008xxxx see XF86keysym.h
(so now there are four versions of Copy/Cut/Paste).
Modern Linux systems (certainly Ubuntu, probably Debian, no experience of
Redhat) seem to map keys to XF86 keysyms where possible. In both gtk-2.0 and
gtk-3.0, gdk/gdkkeysyms.h always uses them where available. Even
gdk/gdkkeysyms-compat.h uses them. So it seems the XF86 keysyms (using
0x1008xxxx) are here to stay, and all the older ones (using 0x100[045]xxxx) and
to be deprecated and reserved to legacy systems (and yes, I realise I have just
relegated Solaris to legacy :-) ).
But Libreoffice (and doubtless Openoffice too) have not got around to accepting
XF86 keysyms yet, and that is the cause of the present bug. However, it is
easily fixed. Within gtksalframe.cxx you will find the function GetKeyCode(),
which I have rewritten (see attached file, which can be included in
gtksalframe.cxx as it stands, provided you attend to the comments about
#include files at the start). It should be OK for either gtk-2.0 or gtk-3.0.
I have not tested this (beyond ensuring that it compiles correctly), but what I
have done is to hack the library
/usr/lib/libreoffice/program/libvclplug_gtklo.so
with a binary editor to achieve the same effect, and it works like a charm.
Note that the Sun keys Props and Front do not have suitable XF86 forms, so they
remain in the 0x1005xxxx form (and Ubuntu, at least, still maps them that way).
Also the Sun key Stop (which gets mapped to the keysym Cancel) has no obvious
KeyCode on the Libreoffice side. You will see that I have mapped it to
KEY_ESCAPE as a temporary measure, but I would strongly recommend that you guys
should invent a KeyCode KEY_CANCEL to make a proper job of it.
I expected some difficulty in binding these keys to their proper functions,
because they did not appear in the Customize-Keyboard popup, but it turns out
that KEY_OPEN, KEY_COPY, KEY_CUT and KEY_PASTE are, by default, bound to their
respective actions as expected and so my personal problem is solved.
Nevertheless, I decided to investigate why they were not appearing in that
popup. It appears that accfg.cxx contains a list
static const sal_uInt16 KEYCODE_ARRAY[] =
{ ... }
which contains all the KeyCodes (with modifiers) that are allowed to appear in
the Customize-Keyboard popup, and from that list it chooses those which appear
to be supported by the hardware. So it uses a huge switch in
SalDisplay::GetKeyName(), which can be found in saldisp.cxx, to obtain a
keysym, then calls XKeysymToKeycode() to get an X11-KeyCode, and if that
succeeds (indicating that such a binding exists), uses XKeysymToString() to
find its name. The trouble is that mapping, say, KEY_COPY to a keysym (the
inverse of what GetKeyCode() does) is one-to-many, so should it try 0x1005FF72
or should it try 0x1008FF57 (or even 0x1000FF02 0x1004FF02). Currently it just
tries 0x1005FF72, which is fine for Solaris, but not for Linux.
I attach a revised version of SalDisplay::GetKeyName(), which calls
GetServerVendor() to discover whether the local system is running Solaris, and
hence which keysyms to use. An alternative would be to use an
#if defined(SOLARIS) ... #endif
to achieve the same effect. I have not tested this code in any way, but I am
sure that it (or something pretty close to it) will solve the problem.
So that's two bugs fixed for you, hopefully, and I hope time can be found to
implement them into your main trunk.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
