Custom Query (308 matches)
Results (46 - 48 of 308)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#331 | invalid | 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 | ||
Description |
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
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: 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,
KeyRelease event, serial 34, synthetic NO, window 0x2600001,
KeyPress event, serial 34, synthetic NO, window 0x2600001,
KeyRelease event, serial 34, synthetic NO, window 0x2600001,
[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:
If you change it to:
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. |
|||
#330 | fixed | Informationschaos auf der Homepage sortieren | ||
Description |
Hoioi! Nachdem ich nun schon neo-Nutzer seit der ersten Version bin, wollte ich mich hier mal informieren, ob eine neue Version in Planung von neo in Planung ist, bevor ich mich daran mache, das Layout für Android umzusetzen (damit man dort auch mit physischen Tastaturen neo schreiben kann). Leider findet man statt sinnvoller Informationen auf der Seite ein ziemliches Informationschaos vor. Ein bunter Mischmasch aus neo1 und neo2. Laut Roadmap ist neo2 übrigens "3 years late" und noch lange nicht abgeschlossen. Interessant, interessant. In irgendwelchen Linkseiten im Wiki bin ich dann über den Begriff "neo 3" gestolpert, sowie einigen Layouts, die anscheinend aus einem Optimierer stammen (ca. eine Stunde nachdem ich die Seite angesurft habe). Irgendwo habe ich auch irgendwas von einem "Neo 2ε" gelesen. Bitte, bitte aktualisiert die Seite und stellt Informationen vernünftig zur Verfügung. Was neo ist, eine _vernünftige_ Versionhierarchie, mit alten, derzeitigen und geplanten Versionen und einem voraussichtlichen Releasetermin. Die Seite ist - so hübsch sie aussieht - derzeit imho nicht zu gebrauchen. Und ob und wann neo 3 oder neo 2ε oder sonst was kommt, habe ich selbst nach einer Stunde noch nicht herausgefunden. Man hat das Gefühl, auf irgendeiner verwaisten Seite herumzugammeln, auf der das letzte Mal vor 5 Jahren irgendwas passiert ist, und die jetzt einfach nur vor sich hin siecht. |
|||
#329 | fixed | Win Remotezugriff: rechte M4 (AltGr) und linke M3 (CapsLock) funktionieren nicht | ||
Description |
Hallo, ich arbeite jetzt an einem Win (XP)-Remote-Rechner, auf dem ich auch NeoVars eingerichtet habe. Plötzlich stellte ich fest, dass die rechte M4 (AltGr) und linke M3 (CapsLock) nicht funktionieren. Ist davon irgendjemandem was bekannt? Wie kann man (ich) das lösen? Danke. Viele Grüße Annette |