Launchpad has imported 22 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=45008.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-01-20T22:24:45+00:00 Christoph Anton Mitterer wrote: Hi. This is forwarded from the mentioned Debian bug: The new version seems to somehow break the F10 key. When being in GNOME, and havin a gnome-terminal opened, e.g. aptitude running... pressing F10 should cause aptitude's menu to open. But now, aptitude's menu opens, as well as the context menu of the terminal itself. Downgrading fixes the issue. Cheers, Chris. Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/0 ------------------------------------------------------------------------ On 2012-01-20T22:29:59+00:00 Sergey V. Udaltsov wrote: what does xev utility reports when you press f10? Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/1 ------------------------------------------------------------------------ On 2012-01-21T08:11:15+00:00 Sven Joachim wrote: I'm having the same problem with gnome-terminal, here is the xev output: KeyPress event, serial 33, synthetic NO, window 0x1400001, root 0x2b5, subw 0x0, time 11437053, (31,432), root:(964,458), state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x1400001, root 0x2b5, subw 0x0, time 11437163, (31,432), root:(964,458), state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/2 ------------------------------------------------------------------------ On 2012-01-21T08:16:40+00:00 Sergey V. Udaltsov wrote: But according to what I see - it is all correct, F10 produces F10. What is xev output with the previous version of xkb-data? > KeyPress event, serial 33, synthetic NO, window 0x1400001, > root 0x2b5, subw 0x0, time 11437053, (31,432), root:(964,458), > state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 0 bytes: > XFilterEvent returns: False > > KeyRelease event, serial 33, synthetic NO, window 0x1400001, > root 0x2b5, subw 0x0, time 11437163, (31,432), root:(964,458), > state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES, > XLookupString gives 0 bytes: > XFilterEvent returns: False Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/3 ------------------------------------------------------------------------ On 2012-01-21T08:34:57+00:00 Sven Joachim wrote: With the previous xkb-data version (2.3), it's essentially the same: KeyPress event, serial 33, synthetic NO, window 0x1600001, root 0x2b5, subw 0x0, time 13172000, (-269,319), root:(664,345), state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x1600001, root 0x2b5, subw 0x0, time 13172097, (-269,319), root:(664,345), state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/4 ------------------------------------------------------------------------ On 2012-01-21T08:46:12+00:00 Sergey V. Udaltsov wrote: Well, in that case God knows why gnome-terminal behaves differently. Ok, one more thing. Could you please do 'xkbcomp :0 -xkb out.xkb' for both new and old versions? Attach the result here Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/5 ------------------------------------------------------------------------ On 2012-01-21T09:05:27+00:00 Sven Joachim wrote: Created attachment 55894 xkbcomp output with xkb-data 2.3 Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/6 ------------------------------------------------------------------------ On 2012-01-21T09:06:58+00:00 Sven Joachim wrote: Created attachment 55895 xkbcomp output with xkb-data 2.5 Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/7 ------------------------------------------------------------------------ On 2012-01-21T13:40:52+00:00 Sergey V. Udaltsov wrote: The definitions for F10 are different (I expected that, I did that change) - but they should not matter if the XKB events are identical (and they are!). What I suspect is that some app (gnome-terminal?) somehow checks the key definition. Why? I have no idea. Something was hardcoded - some workaround, perhaps - there was an issue with functional keys in 2.4. But xev output proves there is nothing to fix in xk-c Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/8 ------------------------------------------------------------------------ On 2012-01-22T00:09:22+00:00 Christoph Anton Mitterer wrote: It's a bit strange simply closing this... and btw: it's not only gnome- terminal that is affected... Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/9 ------------------------------------------------------------------------ On 2012-01-22T00:10:37+00:00 Christoph Anton Mitterer wrote: (Especially as it's clearly triggered by the new xkb-data version). Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/10 ------------------------------------------------------------------------ On 2012-01-22T01:00:10+00:00 Sergey V. Udaltsov wrote: Actually I am ready to reopen if you explain me what exactly would you like me to fix. The x11 (xev) events are absolutely identical - that is the limit of xk-c responsibility, for properly written SW. Is that ok with everybody? If that's the case, the software is using some other information from XKB config - which is should not, I guess Returning to the previous version of F10 definition is not an option because it had clearly broken semantics of things like Shift-F10. So, what would you propose to do? Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/11 ------------------------------------------------------------------------ On 2012-01-22T01:06:08+00:00 Christoph Anton Mitterer wrote: Well has anyone some idea on whose door we should knock now? I mean it's probably some GNOME/GTK wide keyboard library or so? Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/12 ------------------------------------------------------------------------ On 2012-01-22T01:15:11+00:00 Sergey V. Udaltsov wrote: I would start with gnome-terminal perhaps. I am really sorry I cannot be of much help. When you open the bug in gnome bugzilla, could you please provide the link here in comments - so that I could participate in the discussion. Thank you and sorry again. Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/13 ------------------------------------------------------------------------ On 2012-01-22T01:39:50+00:00 Sergey V. Udaltsov wrote: I just tried on my debian, F10 opens g-t menu, aptitide seems not getting it at all. Which is reasonable to some extent... Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/14 ------------------------------------------------------------------------ On 2012-01-22T07:01:56+00:00 Sven Joachim wrote: To reproduce the problem, you need to configure gnome-terminal to pass F10 to the application. Under "Edit → Keyboard Shortcuts", uncheck "Enable the menu shortcut key (F10 by default)". Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/15 ------------------------------------------------------------------------ On 2012-01-22T11:57:10+00:00 Sergey V. Udaltsov wrote: Yes I can reproduce it. That just convinces me that g-t would be a good starting point - I do not know how g-t implements that feature... Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/16 ------------------------------------------------------------------------ On 2012-01-22T15:17:32+00:00 Wettstein509 wrote: > The definitions for F10 are different (I expected that, I did that change) -> > but they should not matter if the XKB events are identical (and they are!). This is not completely true. The new definition of CTRL+ALT consumes Shift, the old one does not. With the new definition, in a pedantic interpretation of section 7.2.1 of the protocol specification of the X Keyboard Extension, applications must not distinguish Shift-F10 and F10 anymore. To see wether this is related to problem at hand, one could replace the definition of CTRL+ALT (file in types/pc) with the following one: type "CTRL+ALT" { modifiers = Control+Alt+Shift+LevelThree; map[None] = Level1; map[Shift] = Level2; map[LevelThree] = Level3; map[Shift+LevelThree] = Level4; map[Control+Alt] = Level5; preserve[Shift] = Shift; preserve[Shift+LevelThree] = Shift; preserve[Shift+LevelThree+Alt] = Shift; preserve[Shift+LevelThree+Control] = Shift; preserve[Shift+LevelThree+Alt+Control] = Shift; preserve[Shift+Alt] = Shift; preserve[Shift+Alt+Control] = Shift; preserve[Shift+Control] = Shift; level_name[Level1] = "Base"; level_name[Level2] = "Shift"; level_name[Level3] = "Alt Base"; level_name[Level4] = "Shift Alt"; level_name[Level5] = "Ctrl+Alt"; }; I do not have gnome on my machine, so I cannot test myself. Note that the above definition is still not nice, but should be ok to check wether consumed Shift is to blame. > Returning to the previous version of F10 definition is not an option because > it > had clearly broken semantics of things like Shift-F10. Do you have a pointer where the problems with the old definition are described? Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/17 ------------------------------------------------------------------------ On 2012-01-22T15:22:39+00:00 Sergey V. Udaltsov wrote: > This is not completely true. The new definition of CTRL+ALT consumes Shift, > the old one does not. How does it affect the behavior of the F10 when shift is not pressed? As you can see, the events are exactly same. > Do you have a pointer where the problems with the old definition are > described? https://bugs.freedesktop.org/show_bug.cgi?id=11822 Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/18 ------------------------------------------------------------------------ On 2012-01-22T16:06:43+00:00 Wettstein509 wrote: > How does it affect the behavior of the F10 when shift is not pressed? As you > can see, the events are exactly same. Basically, as Shift is consumed, one should not distinguish F10 and Shift-F10. This means that pressing Shift-F10 should be handled like pressing F10; or that pressing F10 should be handled like pressing Shift-F10. So it is imaginable that consuming Shift assigns two functions to pressing F10: the usual one for F10, plus the one for Shift-F10. That is the idea. Whether it happens like this, I do not know. One has to try or read the relevant source code. In any event, the original report speaks about two actions triggered by F10... Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/19 ------------------------------------------------------------------------ On 2012-01-26T14:48:18+00:00 Christoph Anton Mitterer wrote: I've reassigned (http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=656685#19) the Debian bug to the GNOME guys... hope they can point us to the right place. Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/20 ------------------------------------------------------------------------ On 2012-01-26T16:14:29+00:00 Sven Joachim wrote: For the record, this has already been reported in GNOME's bugzilla at https://bugzilla.gnome.org/show_bug.cgi?id=661973. Reply at: https://bugs.launchpad.net/gnome- terminal/+bug/937822/comments/21 ** Changed in: gnome-terminal (Debian) Status: Unknown => Confirmed ** Changed in: gnome-terminal Status: Unknown => Won't Fix ** Changed in: gnome-terminal Importance: Unknown => High ** Bug watch added: freedesktop.org Bugzilla #11822 https://bugs.freedesktop.org/show_bug.cgi?id=11822 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/937822 Title: [precise] F10 always opens the menu, cannot be overriden (after xkeyboard-config update) Status in GNOME Terminal: Won't Fix Status in GTK+ GUI Toolkit: Confirmed Status in “gtk+3.0” package in Ubuntu: Confirmed Status in “gnome-terminal” package in Debian: Confirmed Bug description: Upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=661973 Visible in Unity - change keybinding for opening first global menu entry to Alt+F10. Pressing F10 triggers short flash of global menu nevertheless. When you disable the F10 shortcut in gnome-terminal, pressing the key triggers context menu in gnome terminal. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libgtk-3-0 3.3.14-0ubuntu4 ProcVersionSignature: Ubuntu 3.2.0-17.26-generic-pae 3.2.6 Uname: Linux 3.2.0-17-generic-pae i686 ApportVersion: 1.92-0ubuntu1 Architecture: i386 Date: Tue Feb 21 16:29:08 2012 InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20120119) SourcePackage: gtk+3.0 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-terminal/+bug/937822/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
