https://bugs.documentfoundation.org/show_bug.cgi?id=100443
Bug ID: 100443
Summary: Copy/Cut/Paste shortcut keys not recognized
Product: LibreOffice
Version: 4.2 all versions
Hardware: x86 (IA32)
OS: Linux (All)
Status: UNCONFIRMED
Severity: minor
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
Using a Sun Type 6 keyboard on an i86 Linux system.
Keys such as SunFront and Find (indeed most keysyms in
/usr/lib/X11/keysymdef.h) can be used, but the Copy key, in xev, shows
state 0x0, keycode 141 (keysym 0x1008ff57, XF86Copy), same_screen YES,
where that keysym is defined in /usr/lib/X11/XF86keysym.h. Likewise Cut and
Paste. These keys are not recognized.
Realizing that this Bug is likely to be of low priority in getting fixed, I
have been poking around in the Source Code in docs.libreoffice.org, and I am
willing to poke around further if someone here will provide a little
assistance; but at the moment I am lost "in a maze of little twisty passages,
all alike". Here is what I have established so far:
Using gdb on soffice.bin, with a breakpoint at svt::AcceleratorExecute::execute
and pressing the SunProps key (which is recognized but not attached to any
shortcut) I get the stacktrace:
#0 0xb5a0f716 in svt::AcceleratorExecute::execute(KeyCode const&) ()
from /usr/lib/libreoffice/program/libmergedlo.so
#1 0xb579f950 in ?? () from /usr/lib/libreoffice/program/libmergedlo.so
#2 0xb579fa47 in SfxViewShell::KeyInput(KeyEvent const&) ()
from /usr/lib/libreoffice/program/libmergedlo.so
#3 0xaa36d17e in ?? () from /usr/lib/libreoffice/program/../program/libswlo.so
#4 0xb681372f in ?? () from /usr/lib/libreoffice/program/libmergedlo.so
#5 0xb68165e5 in ?? () from /usr/lib/libreoffice/program/libmergedlo.so
#6 0xaf920b1c in ?? () from /usr/lib/libreoffice/program/libvclplug_gtklo.so
#7 0xaf92284d in ?? () from /usr/lib/libreoffice/program/libvclplug_gtklo.so
#8 0xb356febe in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#9 0xb3abfa7e in g_closure_invoke ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#10 0xb3ad2029 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#11 0xb3ad968f in g_signal_emit_valist ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#12 0xb3ad9bf3 in g_signal_emit () from
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#13 0xb369ca03 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#14 0xb356e36c in gtk_propagate_event ()
from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#15 0xb356e690 in gtk_main_do_event ()
from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#16 0xb33e81b8 in ?? () from /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0
#17 0xb40411e3 in g_main_context_dispatch ()
from /lib/i386-linux-gnu/libglib-2.0.so.0
#18 0xb4041468 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#19 0xb4041528 in g_main_context_iteration ()
from /lib/i386-linux-gnu/libglib-2.0.so.0
#20 0xaf90230c in ?? () from /usr/lib/libreoffice/program/libvclplug_gtklo.so
#21 0xaf902c9c in ?? () from /usr/lib/libreoffice/program/libvclplug_gtklo.so
#22 0xb6501271 in Application::Yield() ()
from /usr/lib/libreoffice/program/libmergedlo.so
#23 0xb650130d in Application::Execute() ()
from /usr/lib/libreoffice/program/libmergedlo.so
#24 0xb57ca8b7 in ?? () from /usr/lib/libreoffice/program/libmergedlo.so
#25 0xb6508132 in ?? () from /usr/lib/libreoffice/program/libmergedlo.so
#26 0xb650815d in SVMain() () from /usr/lib/libreoffice/program/libmergedlo.so
#27 0xb57e9765 in soffice_main () from
/usr/lib/libreoffice/program/libmergedlo.so
#28 0x0804858d in ?? ()
#29 0xb431da83 in __libc_start_main (main=0x8048560, argc=3, argv=0xbfe48494,
init=0x8048690, fini=0x8048700, rtld_fini=0xb777e180 <_dl_fini>,
stack_end=0xbfe4848c) at libc-start.c:287
#30 0x080485be in ?? ()
(clearly, my binaries are stripped, hence a lot of "in ??").
Evidently (frame 12) Gtk has emitted a signal for a Keypress Event with the
keysym Sunprops with is caught somewhere in the module libvclplug_gtklo.so.
Evidently also Libreoffice (presumably Openoffice also) uses its own internal
respresentation of what it calls "Keycodes", see
https://docs.libreoffice.org/vcl/html/keycodes_8hxx_source.html in which I
find:
131 #define KEY_CUT ((sal_uInt16)css::awt::Key::CUT)
132 #define KEY_COPY ((sal_uInt16)css::awt::Key::COPY)
133 #define KEY_PASTE ((sal_uInt16)css::awt::Key::PASTE)
134 #define KEY_UNDO ((sal_uInt16)css::awt::Key::UNDO)
135 #define KEY_REPEAT ((sal_uInt16)css::awt::Key::REPEAT)
136 #define KEY_FIND ((sal_uInt16)css::awt::Key::FIND)
137 #define KEY_PROPERTIES ((sal_uInt16)css::awt::Key::PROPERTIES)
so it appears that Libreoffice is comfortable to deal with Copy/Cut/Paste keys
if it manages to see them.
Finding the values of css::awt::Key::CUT and friends is much harder. Yesterday
I found them by legitimate means, but I could not repeat that trail today, and
the best I can do is point you to
https://cgit.freedesktop.org/libreoffice/core/tree/offapi/com/sun/star/awt/Key.idl
where you will find:
module com { module sun { module star { module awt {
.....
published constants Key
{
.....
const short CUT = 1297;
const short COPY = 1298;
const short PASTE = 1299;
const short UNDO = 1300;
const short REPEAT = 1301;
const short FIND = 1302;
const short PROPERTIES = 1303;
and I could see from gdb (see earlier stacktrace) that pressing the SunProps
key had produced a "Keycode" with the value 1303 inside it. Copy/Cut/Paste just
produced the Keycode zero.
It is obvious that, somewhere in the system, there must be some engine that
converts keysyms into "keycodes", but I have been unable to locate it. I have
found, within the vcl module,
a Class GtkSalFrame and, within it,
a Struct GtkSalFrame::IMHandler which has a field
bool GtkSalFrame::IMHandler::handleKeyEvent (GdkEventKey * pEvent)
(see https://docs.libreoffice.org/vcl/html/gtkframe_8hxx_source.html) which
looks like the required tool, but that is only a .hxx file, and I have found no
corresponding .cxx file, nor any clue as to how to initialize a GtkSalFrame
(which presumably would provide an inplemented function to plug into that
field). There is also a Class X11SalFrame with a similar handleKeyEvent() which
takes a raw XEvent, but again with no identifiable function to implement it.
So there I am stuck. If anyone can point me to an implementation of
handleKeyEvent, then I would be happy to investigate further, and maybe suggest
a fix, or at least a workaround. So Thanks in advance for any help that can be
provided.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
