Alt+H is working for me in Slackware 14.0. I'm using a Trinity package set built from git on Sept. 27 (and little has changed in the commits since that date). I tested Alt+H in kate (Help menu), Firefox (non-Trinity app, and in mc (history) in konsole. All are working here.

Possibly a Debian issue?

The problem for me occurs on two unrelated machines. One Debian Squeeze (amd64), the second Debian Wheezy (i386). TDE 3.5.13.2 on same machines without problems. After updating to R14 nightly-build both with the problem.

Hi Slavek,
maybe it could be a keyboard shortcut configuration problem, perhaps at global level.
I use Alt+H and Shift+Alt+H in Midnight Commander running inside Konsole everyday and I never had any problem (Debian/Jessie, TDE built on my own machine).

I remember some years ago I had problem with F10 in Midnight Commander running inside Konsole. F10 was being intercepted by the Konsole shortcut and brought up the Konsole menu (if my memory is right) instead of being passed to MC and exit.
Perhaps your problem with Alt+H is a similar one.

(Odpověď na komentář #3)
> Hi Slavek,
> maybe it could be a keyboard shortcut configuration problem, perhaps at global
> level.
> I use Alt+H and Shift+Alt+H in Midnight Commander running inside Konsole
> everyday and I never had any problem (Debian/Jessie, TDE built on my own
> machine).
> 
> I remember some years ago I had problem with F10 in Midnight Commander running
> inside Konsole. F10 was being intercepted by the Konsole shortcut and brought
> up the Konsole menu (if my memory is right) instead of being passed to MC and
> exit.
> Perhaps your problem with Alt+H is a similar one.

I have two machines, where I observe identical behavior. Both were TDE 3.5.13.2, where the Alt+H was not a problem. After upgrade to R14 with the same user profile is the Alt+H problem. I even tried to remove profile to create a new - default - Alt+H is still problem.

If the Alt+H is set as keyboard shortcut, it is by default => need to change it. However, the current situation is such that Alt+H for me just does do nothing.

I also use Alt+H every day in TDE 3.5.13.2, so this bug is very annoying for me.

I installed a new test machine - plain debian wheezy (netinstall) on it then: aptitude install ksmserver tdm-trinity-trinity tde-i18n-cs-trinity. I turned off the SAK, login in the TDE and ... Alt + H does not work!

The new system, new TDE profile, no influence of the past.

I even tried Ubuntu Nightly CD (2013-10-09) and Alt+H works here.

Interesting. I tried to some global action set a keyboard shortcut Alt+H - action worked. When I removed the assignment, began Alt+H in applications to work properly. After logout / login again Alt+H does not work.

Another observation: I reinstalled the testing machine to a bare Ubuntu 13.04 (mini.iso) and then same as on Wheezy: aptitude install ksmserver-trinity tdm-trinity tde-i18n-cs-trinity, after this turned off the SAK, login in the TDE and ... Alt+H does not work!

Strange thing is that the tested Ubuntu 13.04 TDE Nightly live CD worked! The same installed manually does not work. Really strange.

Another observation: Ubuntu 13.04 TDE Nightly CD launched as a live => Alt+H works. After installing from this CD to disk => Alt+H does not work.

Ha, I found it:

global accel: Walk Through Windows of Same Application
key: Alt+`

When I remove this keyboard shortcut, Alt+H is working properly.
I do not know if key / character >`< depends on locales?

Your discovery rings a bell. I recall we had a discussion a long time ago in the dev mail list with a similar problem --- some kind of quirk behavior with one of the keyboard shortcuts. I don't remember the remedy or result or whether we created a bug report.

Those two shortcuts were added from bug report 869, commit 1e959a2a.

If I remember correctly, it was the keyboard shortcut Ctrl+Alt+S, which is used in the Konsole to rename the konsole and now is set to run screensaver. So far, no changed => no solution.

Here I see two differences:
1) As modifier is used only Alt => potentially conflict with many accelerators in menu and GUI widgets.
2) Shortcut Alt+` affects Alt+H.

>2) Shortcut Alt+` affects Alt+H.
One question is why and another question is why now all of a sudden and not back when commit 1e959a2a was initially pushed?

(Odpověď na komentář #13)
> >2) Shortcut Alt+` affects Alt+H.
> One question is why and another question is why now all of a sudden and not
> back when commit 1e959a2a was initially pushed?

For me it is a very simple explanation - R14 I had for a long time only on a test machine that I do not use for daily work. On 10 October I updated to R14 on one of my work machines. And by this time I run into huge problems in everyday use... as you can see on my other bug reports from the same period.

I've been using pre R14 for the past year. I'm curious why I haven't seen the bug.

I propose to revoke the assignment of the default keyboard shortcuts from commit 1e959a2a. And leave setting suitable keys on the user.

What do you think?

Calvin worked hard on that patch and the shortcuts were important to him. He should have a voice in such a decision.

I haven't had problems with Alt+H or Alt-`. I appreciate how irritating the bug is to you --- and I have my own bug reports I wish were resolved that are irritating to me, but I think we should try to dig deeper why there is a conflict on your system and not other systems. Is this a Debian only problem or something deeper?

I remember Calvin having problems getting one of the shortcuts to function correctly but I don't remember the details. Perhaps there is a link to this bug report?

What happens when you keep the Alt-` shortcut but reassigned to a different task?

I use Debian/Jessie, I have the Alt+` key associated to Walk Through Windows of Same Application as well, but I DON'T have any issue with Alt+H in Konsole.
I guess the root reason for Slavek's problem is somewhere else (plus shortcuts should not affect each other, and if they did something would be really wrong).

Slavek, perhaps it could be something related to the Czech language i18 package? Darrell (I suppose :) ) and I are not using it. I noticed you installed tde-i18n-cs-trinity on your machine. Did you try without it?

> I haven't had problems with Alt+H or Alt-`. I appreciate how irritating the bug
> is to you --- and I have my own bug reports I wish were resolved that are
> irritating to me, but I think we should try to dig deeper why there is a
> conflict on your system and not other systems. Is this a Debian only problem or
> something deeper?
By the way, fully agree with Darrell. I don't think we should revert that commit, since the problem is limited to some systems. We should investigate further and find the real reason, then fix the problem.
Slavek, I also understand how irritating such bug can be, but at least in the meanwhile you have a workaround to be able to avoid the problem until we can find the real problem.

> Darrell (I suppose :) ) and I are not using it.
Note: I do not use any i18n languages.

I am curious to learn whether the problem appears or disappears with other i18n languages.

> Note: I do not use any i18n languages.
> I am curious to learn whether the problem appears or disappears with other i18n
> languages.

For the record, I also do not use any i18n language package

Yes, I also thought that the problem might depend on locales or i18n packages. However, as I mentioned in a comment 8, I tested installation from the LiveCD. The first attempt I set cs_CZ.UTF-8 and Alt+H did not work after installation. In the second attempt, I leave locales at en_US.UTF-8, so the system after instalation to disk is fully in English and Alt+H also does not work!

So I can confidently say: No, it's not locales specific.

(Odpověď na komentář #19)
> > I haven't had problems with Alt+H or Alt-`. I appreciate how irritating the bug
> > is to you --- and I have my own bug reports I wish were resolved that are
> > irritating to me, but I think we should try to dig deeper why there is a
> > conflict on your system and not other systems. Is this a Debian only problem or
> > something deeper?
> By the way, fully agree with Darrell. I don't think we should revert that
> commit, since the problem is limited to some systems. We should investigate
> further and find the real reason, then fix the problem.
> Slavek, I also understand how irritating such bug can be, but at least in the
> meanwhile you have a workaround to be able to avoid the problem until we can
> find the real problem.

Workaround is good - now again I can happily use my system.
But it is not a sufficient solution.

The fact that the problem occurs on a new clean installation with the default language, gives concern that the same problem can also affect many other users. Therefore, I consider it important that the problem was somehow solved before R14 goes out the door.

> The fact that the problem occurs on a new clean installation with the default
> language, gives concern that the same problem can also affect many other users.
> Therefore, I consider it important that the problem was somehow solved before
> R14 goes out the door.
+1 for this :)

Strange; Alt+H works perfectly on my R14 test system (Debian Wheezy, i686).

It does sound like a locales problem on first glance--my guess would not be the language in use so much as the exact charset in use, especially as you note the problem appearing after the LiveCD is installed to the hard disk.  Perhaps something in the TDE code is reading the tilde (~) as something else entirely and stopping the shortcut execution stack prematurely.

What is the output of "env | grep LANG" from within a Konsole session exhibiting this problem?  On my system the output is "LANG=en_US.UTF-8".

Thanks!

> What is the output of "env | grep LANG" from within a Konsole session
> exhibiting this problem?  On my system the output is "LANG=en_US.UTF-8".

On my system it is also "LANG=en_US.UTF-8".

By the way Slavek, which keyboard layout do you use? Mine is English (US), and I guess Tim and Darrell are using the same.

(In reply to comment #25)
> Strange; Alt+H works perfectly on my R14 test system (Debian Wheezy, i686).
> 
> It does sound like a locales problem on first glance--my guess would not be the
> language in use so much as the exact charset in use, especially as you note the
> problem appearing after the LiveCD is installed to the hard disk.  Perhaps
> something in the TDE code is reading the tilde (~) as something else entirely
> and stopping the shortcut execution stack prematurely.

Sorry, that should be "back quote" (`) above, not tilde.  I can in fact read if I try hard enough. ;-)

(In reply to comment #26)
> > What is the output of "env | grep LANG" from within a Konsole session
> > exhibiting this problem?  On my system the output is "LANG=en_US.UTF-8".
> 
> On my system it is also "LANG=en_US.UTF-8".
> 
> By the way Slavek, which keyboard layout do you use? Mine is English (US), and
> I guess Tim and Darrell are using the same.

English (US), i.e. en_US.UTF-8

OK, so using the en_US.UTF-8 locale does not fix the problem.  Interesting.

TDE stores the global shortcuts in ~/.trinity/share/config/kdeglobals  Can you please compress and attach the kdeglobals file from a malfunctioning system to this bug report?  The compression should preserve the binary data within the text file for analysis on this end--without compression it is conceivable that Bugzilla could convert it from one character format to another.

Thanks!

Tim

> > On my system it is also "LANG=en_US.UTF-8".
> > 
> > By the way Slavek, which keyboard layout do you use? Mine is English (US), and
> > I guess Tim and Darrell are using the same.
> 
> English (US), i.e. en_US.UTF-8
> 
> OK, so using the en_US.UTF-8 locale does not fix the problem.  Interesting.

Actually Tim, on my system (Debian/Jessie i686, en_US.UTF-8 locale and English(US) keyboard layout) Alt+H is working fine.
I just posted my settings to provide Slavek with more information about a working system.

(In reply to comment #28)
> > > On my system it is also "LANG=en_US.UTF-8".
> > > 
> > > By the way Slavek, which keyboard layout do you use? Mine is English (US), and
> > > I guess Tim and Darrell are using the same.
> > 
> > English (US), i.e. en_US.UTF-8
> > 
> > OK, so using the en_US.UTF-8 locale does not fix the problem.  Interesting.
> 
> Actually Tim, on my system (Debian/Jessie i686, en_US.UTF-8 locale and
> English(US) keyboard layout) Alt+H is working fine.
> I just posted my settings to provide Slavek with more information about a
> working system.

Sorry about that.  I have been out of town for several days and am trying to catch up somewhat with the long list of bugs.

When Slavek posts the kdeglobals file from the malfunctioning system, I suspect that the line in that file related to "Walk Through Windows of Same Application" will be different than your and my systems.  If not, then the global shortcut parser code itself is suspect.

Created attachment 1576 [details]
kdeglobals from new test machine

This is the configuration file from newly installed test machine. When installing everything was left at the default values ​​=> locales are fully en_US.UTF-8, english keyboard.

One observation: On Czech keyboard to write the >`< character is used AltGr together with key containing >~< and >`<. When I'm on current TDE 3.5.13.2 try pressing Alt + AltGr + key >`< is displayed as a result of Alt+H. It seems that it is not a new bug in R14.

Oops. Now I checked test machine with newly installed Ubuntu, although I did not set, I see in configuration XKBLAYOUT="cz". This explains why the newly installed machine behaves badly.

Ha, one more observation: AltGr+H on Czech keyboard writes character >`<. This probably explains the problem. While on Czech keyboard AltGr serving for another purpose, for shortcuts is perceived as a normal Alt.

(In reply to comment #32)
> Ha, one more observation: AltGr+H on Czech keyboard writes character >`<. This
> probably explains the problem. While on Czech keyboard AltGr serving for
> another purpose, for shortcuts is perceived as a normal Alt.

Hi Slavek,
I am not on a TDE machine at the moment (so I write by memory), but if you go to the Control center -> Regionals settings -> Keyboard layout, there is the possibility to see what key is associated with all special keys (Ctrl, Shift, Meta, ....).
You can check there whether AltGr is the same as Alt (in most cases it is). And if I remember correctly, you can even change those settings. 
I will double check later when I am on a TDE machine.

> Hi Slavek,
> I am not on a TDE machine at the moment (so I write by memory), but if you go
> to the Control center -> Regionals settings -> Keyboard layout, there is the
> possibility to see what key is associated with all special keys (Ctrl, Shift,
> Meta, ....).
> You can check there whether AltGr is the same as Alt (in most cases it is). And
> if I remember correctly, you can even change those settings. 
> I will double check later when I am on a TDE machine.

Just checked on a TDE machine.
Control center -> Regional & accessibility -> Keyboard shortcut -> Modifier keys

Created attachment 1579 [details]
Keyboard shortcut -> Modifier
keys

I do not see anything that would apply to Alt_R.

I found a piece of code that is a little suspect.
Related to bug reports:

http://lists.debian.org/debian-qt-kde/2004/12/msg00427.html
https://bugs.kde.org/show_bug.cgi?id=96621

In the code is for finding keyNative ignored state 0x2000. But this state is subsequently ignored even for other work with 'keyNative', hence 'key', hence 'TQKeyEvent'. The code is identical in tdeaccel.cpp - from line 130.

Created attachment 1584 [details]
key modifiers image

> Keyboard shortcut -> Modifier keys
> I do not see anything that would apply to Alt_R.
This is my system key modifiers. Here I have Alt_L and Alt_R (AltGr) to be the same

So fundamentally this bug is due to TQt3/TDE not differentiating between the Alt/AltGr keys when processing shortcuts, which then causes a conflict between the global shortcut Alt+` and the local shortcut Alt+H (due to the latter being interpreted as AltGr+H == Alt+`).

As an aside, since this is not well documented, for those using en_US keyboard layouts, the following command will enable the AltGr key:
setxkbmap -layout us -variant altgr-intl

I just tested the cz keyboard layout in Kate and Alt+H opened the Help menu, while AltGr+H wrote a '`' character.  This would seem to indicate that the shortcut parsing code works properly.

Slavek, is your keyboard configured with a separate AltGr key, or do you have two standard Alt keys and no AltGr key?

Thanks!

I have a keyboard layout pc105. Pressing AltGr+H correctly write char '`'. Pressing Alt+H will do nothing. When I turn off the default shortcut assigned to Walk Through Windows of Same Application, Alt+H works correctly - in my case opens menu Pohled.

As can be seen in the difference attachment 1576 [details] and
attachment 1584 [details] in my case AltGr is not considered as Mod1.

> As can be seen in the difference attachment 1576 [details] and
> attachment 1584 [details] in my case AltGr is not considered as Mod1.

Slavek, have a look at this link, it's about XKB extension. In particular
https://wiki.archlinux.org/index.php/X_KeyBoard_extension

In particular see the section about the key modifier settings, there is an example about Alt_L and Alt_R that may be useful.
https://wiki.archlinux.org/index.php/X_KeyBoard_extension#modifier_map

(Odpověď na komentář #41)
> > As can be seen in the difference attachment 1576 [details] [details] and
> > attachment 1584 [details] [details] in my case AltGr is not considered as Mod1.
> 
> Slavek, have a look at this link, it's about XKB extension. In particular
> https://wiki.archlinux.org/index.php/X_KeyBoard_extension
> 
> In particular see the section about the key modifier settings, there is an
> example about Alt_L and Alt_R that may be useful.
> https://wiki.archlinux.org/index.php/X_KeyBoard_extension#modifier_map

For years, I have the keyboard set as well. And everything works as it should. I use AltGr for many characters and I have no problems with it.

Problem with Alt + H is the first problem. Therefore, I do not think I had a problem with setting the keyboard.

I'm getting nowhere trying to reproduce this bug with the Czech keyboard enabled on my test system.  Can you post your /etc/default/keyboard file just to make sure our settings are the same?

Thanks!

(Odpověď na komentář #43)
> I'm getting nowhere trying to reproduce this bug with the Czech keyboard
> enabled on my test system.  Can you post your /etc/default/keyboard file just
> to make sure our settings are the same?
> 
> Thanks!

XKBMODEL="pc105"
XKBLAYOUT="cz"
XKBVARIANT=""
XKBOPTIONS=""

However, I usually use the keyboard layout in TDE - Control Center / Regional & Accessibility / Keyboard Layout.

Does changing

XKBOPTIONS=""

to 

XKBOPTIONS="lv3:ralt_switch"

in /etc/default/keyboard fix the problem?

(In reply to comment #45)
> Does changing
> 
> XKBOPTIONS=""
> 
> to 
> 
> XKBOPTIONS="lv3:ralt_switch"
> 
> in /etc/default/keyboard fix the problem?

Never mind, wasn't thinking. ;-)  Can you instead post the command line shown at the bottom of the TDE --> Control Center / Regional & Accessibility / Keyboard Layout --> Xkb Options tab?

Thanks!

(Odpověď na komentář #46)
> (In reply to comment #45)
> > Does changing
> > 
> > XKBOPTIONS=""
> > 
> > to 
> > 
> > XKBOPTIONS="lv3:ralt_switch"
> > 
> > in /etc/default/keyboard fix the problem?
> 
> Never mind, wasn't thinking. ;-)  Can you instead post the command line shown
> at the bottom of the TDE --> Control Center / Regional & Accessibility /
> Keyboard Layout --> Xkb Options tab?
> 
> Thanks!

On Xkb Options tab I have no command.
On Layout tab I have command: setxkbmap -model pc105 -layout cz

Note that RAlt combinations for me on Czech keyboard wrote right chars - for example RAlt+Q => \, RAlt+C => &, RAlt+X => #, RAlt+H => `.

(In reply to comment #47)
> On Xkb Options tab I have no command.
> On Layout tab I have command: setxkbmap -model pc105 -layout cz
> 
> Note that RAlt combinations for me on Czech keyboard wrote right chars - for
> example RAlt+Q => \, RAlt+C => &, RAlt+X => #, RAlt+H => `.

This might be a clue, as I always need to set RAlt to Level 3.  Can you post the exact make and model of your keyboard?

Thanks!

(Odpověď na komentář #48)
> (In reply to comment #47)
> > On Xkb Options tab I have no command.
> > On Layout tab I have command: setxkbmap -model pc105 -layout cz
> > 
> > Note that RAlt combinations for me on Czech keyboard wrote right chars - for
> > example RAlt+Q => \, RAlt+C => &, RAlt+X => #, RAlt+H => `.
> 
> This might be a clue, as I always need to set RAlt to Level 3.  Can you post
> the exact make and model of your keyboard?
> 
> Thanks!

I think that it does not depend on the type of keyboard. On my machines I have (old) Microsoft Natural Keyboard and Microsoft Natural Ergonomic Keyboard 4000. But the problem I have observed even on testing machine with an ordinary keyboard (I think some Geninus), but also on a virtual testing machine with a virtual keyboard :)

(In reply to comment #49)
> (Odpověď na komentář #48)
> > (In reply to comment #47)
> > > On Xkb Options tab I have no command.
> > > On Layout tab I have command: setxkbmap -model pc105 -layout cz
> > > 
> > > Note that RAlt combinations for me on Czech keyboard wrote right chars - for
> > > example RAlt+Q => \, RAlt+C => &, RAlt+X => #, RAlt+H => `.
> > 
> > This might be a clue, as I always need to set RAlt to Level 3.  Can you post
> > the exact make and model of your keyboard?
> > 
> > Thanks!
> 
> I think that it does not depend on the type of keyboard. On my machines I have
> (old) Microsoft Natural Keyboard and Microsoft Natural Ergonomic Keyboard 4000.
> But the problem I have observed even on testing machine with an ordinary
> keyboard (I think some Geninus), but also on a virtual testing machine with a
> virtual keyboard :)

VirtualBox?  If so I can test this real quick!

Tim

(Odpověď na komentář #50)
> VirtualBox?  If so I can test this real quick!
> 
> Tim

Unfortunately - I use KVM.

(In reply to comment #51)
> (Odpověď na komentář #50)
> > VirtualBox?  If so I can test this real quick!
> > 
> > Tim
> 
> Unfortunately - I use KVM.

OK, I can now replicate this with VirtualBox.  To replicate, the TDE keyboard switcher must be disabled, and the /etc/defaults/keyboard file must *only* contain the "cz" layout option.

(In reply to comment #52)
> (In reply to comment #51)
> > (Odpověď na komentář #50)
> > > VirtualBox?  If so I can test this real quick!
> > > 
> > > Tim
> > 
> > Unfortunately - I use KVM.
> 
> OK, I can now replicate this with VirtualBox.  To replicate, the TDE keyboard
> switcher must be disabled, and the /etc/defaults/keyboard file must *only*
> contain the "cz" layout option.

Thus far I have been able to determine that the code in tdeaccel.cpp:130 receives three separate keyboard events (Alt keypress [code 64], something with code 203, then the H keypress [code 43]) under the US keyboard layout, while it only receives the first event (Alt keypress [code 64]) under the CZ keyboard layout.  It seems that something else is intercepting the two subsequent keypresses--possibly the global accelerator class.

Still working on this...

Getting closer...killing twin restores the Alt+H functionality.

(Odpověď na komentář #54)
> Getting closer...killing twin restores the Alt+H functionality.

There is no need to kill twin - just for the action Walk Through Windows of Same Application set none or another shortcut.

Because it seems to me that it is correctly evaluated RAlt+H => `, but tdeaccel this press '`' then incorrectly treated as Alt+`.

(In reply to comment #55)
> (Odpověď na komentář #54)
> > Getting closer...killing twin restores the Alt+H functionality.
> 
> There is no need to kill twin - just for the action Walk Through Windows of
> Same Application set none or another shortcut.
> 
> Because it seems to me that it is correctly evaluated RAlt+H => `, but tdeaccel
> this press '`' then incorrectly treated as Alt+`.

Killing twin simply showed that it )or a library it uses) is the culprit.  It led me to discover that twin calls this method when it should not:

grabKey( key: 'Alt+H', bGrab: 1 ): keyCodeX: 2b keyModX: 8

This in turn appears to be called from TDEAccelBase::updateConnections()

(In reply to comment #56)
> (In reply to comment #55)
> > (Odpověď na komentář #54)
> > > Getting closer...killing twin restores the Alt+H functionality.
> > 
> > There is no need to kill twin - just for the action Walk Through Windows of
> > Same Application set none or another shortcut.
> > 
> > Because it seems to me that it is correctly evaluated RAlt+H => `, but tdeaccel
> > this press '`' then incorrectly treated as Alt+`.
> 
> Killing twin simply showed that it )or a library it uses) is the culprit.  It
> led me to discover that twin calls this method when it should not:
> 
> grabKey( key: 'Alt+H', bGrab: 1 ): keyCodeX: 2b keyModX: 8
> 
> This in turn appears to be called from TDEAccelBase::updateConnections()

There is one other interesting item in that the default TDEAccel mapping for twin looks like this:

tdecore (TDEAccel):     code: 9 mod: c name: "Kill Window" shortcut: Alt+Ctrl+Escape
tdecore (TDEAccel):     code: 17 mod: 8 name: "Walk Through Windows" shortcut: Alt+Tab
tdecore (TDEAccel):     code: 17 mod: 9 name: "Walk Through Windows (Reverse)" shortcut: Alt+Shift+Tab
tdecore (TDEAccel):     code: 26 mod: c name: "Activate Window Demanding Attention" shortcut: Alt+Ctrl+A
tdecore (TDEAccel):     code: 26 mod: 2008 name: "Walk Through Windows of Same Application (Reverse)" shortcut: Alt+Asciitilde
tdecore (TDEAccel):     code: 2b mod: 2008 name: "Walk Through Windows of Same Application" shortcut: Alt+Grave
tdecore (TDEAccel):     code: 43 mod: 4 name: "Switch to Desktop 1" shortcut: Ctrl+F1
tdecore (TDEAccel):     code: 43 mod: 5 name: "Switch to Desktop 13" shortcut: Ctrl+Shift+F1
tdecore (TDEAccel):     code: 44 mod: 4 name: "Switch to Desktop 2" shortcut: Ctrl+F2
tdecore (TDEAccel):     code: 44 mod: 5 name: "Switch to Desktop 14" shortcut: Ctrl+Shift+F2
tdecore (TDEAccel):     code: 45 mod: 4 name: "Switch to Desktop 3" shortcut: Ctrl+F3
tdecore (TDEAccel):     code: 45 mod: 5 name: "Switch to Desktop 15" shortcut: Ctrl+Shift+F3
tdecore (TDEAccel):     code: 45 mod: 8 name: "Window Operations Menu" shortcut: Alt+F3
tdecore (TDEAccel):     code: 46 mod: 4 name: "Switch to Desktop 4" shortcut: Ctrl+F4
tdecore (TDEAccel):     code: 46 mod: 5 name: "Switch to Desktop 16" shortcut: Ctrl+Shift+F4
tdecore (TDEAccel):     code: 46 mod: 8 name: "Window Close" shortcut: Alt+F4
tdecore (TDEAccel):     code: 47 mod: 4 name: "Switch to Desktop 5" shortcut: Ctrl+F5
tdecore (TDEAccel):     code: 47 mod: 5 name: "Switch to Desktop 17" shortcut: Ctrl+Shift+F5
tdecore (TDEAccel):     code: 48 mod: 4 name: "Switch to Desktop 6" shortcut: Ctrl+F6
tdecore (TDEAccel):     code: 48 mod: 5 name: "Switch to Desktop 18" shortcut: Ctrl+Shift+F6
tdecore (TDEAccel):     code: 49 mod: 4 name: "Switch to Desktop 7" shortcut: Ctrl+F7
tdecore (TDEAccel):     code: 49 mod: 5 name: "Switch to Desktop 19" shortcut: Ctrl+Shift+F7
tdecore (TDEAccel):     code: 4a mod: 4 name: "Switch to Desktop 8" shortcut: Ctrl+F8
tdecore (TDEAccel):     code: 4a mod: 5 name: "Switch to Desktop 20" shortcut: Ctrl+Shift+F8
tdecore (TDEAccel):     code: 4b mod: 4 name: "Switch to Desktop 9" shortcut: Ctrl+F9
tdecore (TDEAccel):     code: 4c mod: 4 name: "Switch to Desktop 10" shortcut: Ctrl+F10
tdecore (TDEAccel):     code: 5f mod: 4 name: "Switch to Desktop 11" shortcut: Ctrl+F11
tdecore (TDEAccel):     code: 60 mod: 4 name: "Switch to Desktop 12" shortcut: Ctrl+F12
tdecore (TDEAccel):     code: 60 mod: 8 name: "Mouse Emulation" shortcut: Alt+F12
tdecore (TDEAccel):     code: 6b mod: 4 name: "Desktop Screenshot" shortcut: Ctrl+Print
tdecore (TDEAccel):     code: 6b mod: 8 name: "Window Screenshot" shortcut: Alt+Print

Note that "Walk Through Windows of Same Application" and "Walk Through Windows of Same Application (Reverse) both have an additional modifier set (possibly Level 3?).  That might be the origin of the problem.

This should be fixed in GIT hash 05e764a.  In a nutshell, accelerator sequences that rely on AltGr being used as the MODE_SHIFT modifier cannot be used with X11.  TDE stripped off the MODE_SHIFT modifier before calling XGrabKey, causing the wrong key to be grabbed.

This may be more obvious when looking at the Czech keyboard layout:
http://commons.wikimedia.org/wiki/File:Keyboard_layout_Czech.svg

Note that there is no way to access the Grave accent character without using the AltGr (MODE_SHIFT) key.  This means that the global shortcut Alt+` will not work on some keyboard layouts.

(In reply to comment #58)
> This should be fixed in GIT hash 05e764a.  In a nutshell, accelerator sequences
> that rely on AltGr being used as the MODE_SHIFT modifier cannot be used with
> X11.  TDE stripped off the MODE_SHIFT modifier before calling XGrabKey, causing
> the wrong key to be grabbed.
> 
> This may be more obvious when looking at the Czech keyboard layout:
> http://commons.wikimedia.org/wiki/File:Keyboard_layout_Czech.svg
> 
> Note that there is no way to access the Grave accent character without using
> the AltGr (MODE_SHIFT) key.  This means that the global shortcut Alt+` will not
> work on some keyboard layouts.

Sorry, MODE_SHIFT should be MODE_SWITCH above.

Please confirm the fix and mark resolved if it is acceptable to you.

Thanks!

Great, it works!

In xsession-errors are listed warnings and Alt+H is again in operation.

tdecore (TDEAccel): WARNING: TDEGlobalAccelPrivate::grabKey( Alt+A, true, "Walk Through Windows of Same Application (Reverse)" ): Tried to grab key requiring ISO_Level3_Shift (AltGr) sequence.
tdecore (TDEAccel): WARNING: TDEGlobalAccelPrivate::grabKey( Alt+H, true, "Walk Through Windows of Same Application" ): Tried to grab key requiring ISO_Level3_Shift (AltGr) sequence.

Thanks a lot.