#331: linux - xubuntu 12.04 LTS - meld 1.5.3 - neo2.0 causes bug in meld (on
three totally different(->hardware) notebooks, but all running xubuntu
12.04 LTS
---------------------------------------+------------------------------------
Reporter: erik.schaff@… | Owner:
Type: Fehler/Defekt | Status: new
Priority: normal | Milestone: Neo Version 2.0
Component: unbekannt | Version: 2.0 Final
Keywords: meld ubuntu 12.04 neo 2.0 |
---------------------------------------+------------------------------------
system: xubuntu 12.04 LTS (32 bit and 64 bit, on both architectures)
neo2.0 dependent: yes, because in standard qwertz (de) layout no bug
appears using meld.
description:
First, I thought it is a meld bug therefore see as well:
https://bugzilla.gnome.org/show_bug.cgi?id=683534
Keyboard layout: German, in special mode/variant: NEO 2.0
When pushing one of the shift keys on my lenovo external thinkpad-like usb
keyboard the little arrows in the split boarder of meld (two-file-compare-
mode) change to crosses.
But when I release the same shift button, the crosses (deleting mode)
don't
switch back to little arrows (replacing mode).
They keep on, like a kind of sticky behaviour.
Annoying orkaround: I have to open any arbitrary dialog-window inside
Meld, e.g. Help
> About.
After closing the window, everything is fine back in original state
(little
arrows instead of crosses)
Surprisingly this only happens with the shift button to me, the Control
one
works like it should. (pushed: add-mode, released: replace-mode).
Seems to be a problem with keyboard layout NEO 2.0
in standard german layout, bug does not appear. Any help? How is this
shortcut
encoded in Meld?
[reply] [-] Comment 1 Kai Willadsen [meld developer] 2012-09-18 19:35:11
UTC
Essentially, Meld listens for a key-up event for Ctrl, Shift, etc., but
some
layouts don't actually emit key-ups for some modifier keys. I don't know
anything about the NEO 2.0 layout, so I don't know why it would fail where
others work.
This sounds exactly like an old problem with layout switching and
modifiers
(bug 584342). Could you please have a look at that bug, and see if any of
the
debugging there gives us extra information? It may be that we just need to
add
another key symbol to the existing workaround.
[reply] [-] Comment 2 Erik [reporter] 2012-09-20 17:27:08 UTC
Sorry, but all of this long communication there did not help me.
I am using three different PC (totally different hardware) and on all
three
there is Xubuntu 12.04 running and the neo 2.0 layout. see:
http://www.neo-layout.org/
all these work around with "press ctlr, then..." and so on, no help for
me.
as I am not at all experienced with xkb settings and stuff... sorry, can't
help
a lot and I do not have the time to dive into these tecnical issues...
[reply] [-] Comment 3 Kai Willadsen [meld developer] 2012-09-20 20:46:10
UTC
The easiest way to get the key event data is to run 'xev' from the command
line. Ignore the initial output. Press and then release Shift, press and
then
release Ctrl. Then please copy xev's output for just those four events and
and
paste it here. (If you look at the bug I linked, comment 17 has an example
of
the kind of output I need.)
[reply] [-] Comment 4 Erik [reporter] 2012-09-20 21:12:07 UTC
KeyPress event, serial 34, synthetic NO, window 0x2600001,
root 0xc5, subw 0x0, time 908497, (255,-185), root:(966,343),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x2600001,
root 0xc5, subw 0x0, time 909713, (255,-185), root:(966,343),
state 0x1, keycode 50 (keysym 0xffe5, Caps_Lock), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 34, synthetic NO, window 0x2600001,
root 0xc5, subw 0x0, time 922425, (255,-185), root:(966,343),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x2600001,
root 0xc5, subw 0x0, time 923201, (255,-185), root:(966,343),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
[reply] [-] Comment 5 Kai Willadsen [meld developer] 2012-09-20 21:21:35
UTC
Thanks. This looks to me like a bug with the neo layout. The problem is
that
when you push down Shift, it sends KeyPress Shift, but when you release
Shift
it sends KeyRelease Caps_Lock. Looking at the Neo bugs it looks (to my
very
broken German) like the layout already has bugs reported against it for
its
Shift/Capslock behaviour. e.g., http://wiki.neo-layout.org/ticket/243
Given that, I'm going to close this bug as being not Meld. If you want a
workaround, you should be able to change on_key_release_event in
filediff.py.
The last clause there currently looks like:
elif event.keyval == gtk.keysyms.ISO_Prev_Group:
If you change it to:
elif event.keyval == gtk.keysyms.ISO_Prev_Group or event.keyval ==
gtk.keysyms.Caps_Lock:
then I suspect that that should work, though I haven't tested this. I
really
can't justify adding this workaround to Meld though, as this looks like a
straight-up bug with the layout.
--
Ticket URL: <http://wiki.neo-layout.org/ticket/331>
Neo-Layout <http://neo-layout.org/>
Das Neo-Tastaturlayout ist ein freies und ergonomisch optimiertes
Tastaturlayout für die deutsche Sprache, das auch sehr viele Sonderzeichen
direkt verfügbar macht.
