xterm shortcut sometimes doesn't work with alternate keymap

Bug #38750 reported by Matthew Phillips
8
Affects Status Importance Assigned to Milestone
control-center (Ubuntu)
New
Low
Ubuntu Desktop Bugs

Bug Description

I'm using Dapper (installed from a recent nightly build and all packages up to date)

I have gnome set up to use the dvoark keymap by default (The default system keymap is US). I have the open xterm shortcut set up as crtl + alt + q (in dvorak q corresponds to the x key). Often when I log in this shortcut stops working. The shortcut behaves as if it is mapped in the US layout. So if I push crtl + alt + q (where q is the us q and not the dvorak q) the shortcut will work.

I have mapped two other custom shortcut keys (crtl + alt + w and v) using gconftool. These also do not work. However my web browser shortcut crtl + alt + c does work and things like alt f4 work fine.

If I open up the keyboard shortcuts menu and map open xterm to another key and then map it back all of my shortcuts start to work.

This problem seems to happen most of the time when I log in now but not all of the time. I haven't been able to determine what might cause it.

I don't think this problem is related to #2561 because shortcuts in firefox and gnome terminal still work correctly. It could somehow be related to #32860. A separate issue I have noticed that occurs at the same time as this problem is the lock screen option from the System menu does not work when I first log in. I can click it as many times as I want but it won't work until I launch another application such as nautilus or an gnome-terminal.

Here's some output I have noticed that has been requested for other keyboard related bugs:

xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc104", "us", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc104", "us,us", "dvorak,", "grp:shift_caps_toggle"

gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
layouts = [us dvorak,us]
model =
options = [grp grp:shift_caps_toggle]
overrideSettings = true

locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en_US:en_GB:en
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME="en_CA.UTF-8"
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER="en_CA.UTF-8"
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for you bug. I'm not sure that's a GNOME issue, looks like a xkeyboard-config issue maybe. Do you still have the issue?

Changed in control-center:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Matthew Phillips (mephillips) wrote : Re: [Bug 38750] Re: xterm shortcut sometimes doesn't work with alternate keymap

The problem does still happen. I haven't been able to determine what
causes it. Sometimes when I log in the shortcuts will work properly.
Other times they won't. Perhaps it is some strange combination of
settings that I have chosen. I will be doing a fresh install when
Dapper is released. I can let you know if the problem persists.

On 5/31/06, Sebastien Bacher <email address hidden> wrote:
> Thanks for you bug. I'm not sure that's a GNOME issue, looks like a
> xkeyboard-config issue maybe. Do you still have the issue?
>
> ** Changed in: control-center (Ubuntu)
> Severity: Normal => Minor
> Assignee: (unassigned) => Ubuntu Desktop Bugs
> Status: Unconfirmed => Needs Info
>
> --
> xterm shortcut sometimes doesn't work with alternate keymap
> https://launchpad.net/bugs/38750
>

Revision history for this message
Sebastien Bacher (seb128) wrote :

Reopening, maybe somebody knows about it or is willing to investigate
For my part I don't know details of keyboard handling and I don't use dvorak and I've already to many bugs to look at

Changed in control-center:
status: Needs Info → Unconfirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.