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 #331

New Issue

erik.schaff · 2012-09-21T19:02:56+02:00

erik.schaff commented

2012-09-21 19:02:56 +02:00

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.

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.

erik.schaff added the

Bug

label 2012-09-21 19:02:56 +02:00

erik commented

2012-09-21 23:42:03 +02:00

Achtung: Ich bin nicht der Erik, der den Fehler gemeldet hat.

Ah, genau diese Fehler nervt mich auch schon seit Jahren. Dachte ich wäre der einzige mit dem Problem. Den Workaround kannte ich noch nicht (mit dem „ins Menü klicken“).

Ich nutze Fedora Linux. Der Fehler tritt dort mindestens seit Version 12 auf. Momentan nutze ich Version 17 (von Fedora) und der Fehler ist noch immer nicht weg.

Vielleicht kann Stephan Hilb dazu was sagen.

Ich nutze übrigens nicht die xkbmap, sondern die xmodmap (weil ich die Truly-Tastatur verwende und da ein paar Änderungen notwendig sind, die per Xmodmap einfacher umsetzbar sind). Dort Tritt der Fehler auch auf. Und auch mit der Shift-Taste. Beim Key-Release wird dort allerdings Shift-Lock gesendet und nicht Caps-Lock.

Achtung: Ich bin nicht der Erik, der den Fehler gemeldet hat. Ah, genau diese Fehler nervt mich auch schon seit Jahren. Dachte ich wäre der einzige mit dem Problem. Den Workaround kannte ich noch nicht (mit dem „ins Menü klicken“). Ich nutze Fedora Linux. Der Fehler tritt dort mindestens seit Version 12 auf. Momentan nutze ich Version 17 (von Fedora) und der Fehler ist noch immer nicht weg. Vielleicht kann Stephan Hilb dazu was sagen. Ich nutze übrigens nicht die xkbmap, sondern die xmodmap (weil ich die Truly-Tastatur verwende und da ein paar Änderungen notwendig sind, die per Xmodmap einfacher umsetzbar sind). Dort Tritt der Fehler auch auf. Und auch mit der Shift-Taste. Beim Key-Release wird dort allerdings Shift-Lock gesendet und nicht Caps-Lock.

Stephan closed this issue

2012-09-22 11:31:43 +02:00

Stephan added the

Invalid

label 2012-09-22 11:31:43 +02:00

Stephan commented

2012-09-22 11:31:43 +02:00

Ich habe in dem gnome-ticket mal geschrieben, was meine Meinung dazu ist:

https://bugzilla.gnome.org/show_bug.cgi?id=683534

Wir könnten eventuell dem entgegenkommen, indem wir mit actions statt mit den keysyms arbeiten um das capslock Verhalten zu bewerkstelligen. Trotzdem meine ich, dass uns die Schuld eigentlich nicht trifft (siehe mein Beispiel in dem Ticket, warum es schlecht ist keysyms zu prüfen bei keypress/release events).

Sollte jemand anderer Meinung sein, kann er das Ticket wieder aufmachen.

Ich habe in dem gnome-ticket mal geschrieben, was meine Meinung dazu ist: https://bugzilla.gnome.org/show_bug.cgi?id=683534 Wir könnten eventuell dem entgegenkommen, indem wir mit actions statt mit den keysyms arbeiten um das capslock Verhalten zu bewerkstelligen. Trotzdem meine ich, dass uns die Schuld eigentlich nicht trifft (siehe mein Beispiel in dem Ticket, warum es schlecht ist keysyms zu prüfen bei keypress/release events). Sollte jemand anderer Meinung sein, kann er das Ticket wieder aufmachen.

Stephan commented

2012-10-03 00:13:08 +02:00

Ist mittlerweile in meld gefixed, siehe gnome bug.

Sign in to join this conversation.

No Milestone

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: neo/neo-layout#331