Bug 309754

Summary:	Use Key above Tab instead of ~ (US layout) for Walk Through Windows of Current Application
Product:	[Plasma] kwin	Reporter:	David Martí <neikokz+kbugs>
Component:	tabbox	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	CONFIRMED ---
Severity:	wishlist	CC:	bugseforuns, christiandehne, franjesus, gabriello.ramirez, kde, kwin-bugs-null
Priority:	NOR
Version First Reported In:	4.9.2
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description David Martí 2012-11-08 16:28:36 UTC

I see that, since KDE 4.9 (or maybe before), Alt+~ has been added to the list of default shortcuts for KWin.

Since ~ is AltGr+4 in the Spanish keyboard, now, and I don't know why, it is not possible to use Alt+4 in any application (for example, in Chrome, Irssi... to switch between tabs). So Alt+4 doesn't work anymore in KDE and it's very very hard for the users to guess why.

Reproducible: Always

Comment 1 Thomas Lübking 2012-11-08 17:02:47 UTC

Bug is in kglobalacceld, but i don't even know whether it's resolvable.

AltGr is the 3rd level shifter and the only event on the server is the logical 3rd level key (~) not the physical key (4)

Regardless of that thesituation is crap anyway because the shortcut ends up being on such a distant key, while physically it should be the one above the tabulator (us layout, "^" on eg. the de layout) so i wonder whether shortcuts should be subject tol i18n *shrug*

Comment 2 Gabriel Ramirez 2013-03-01 05:38:21 UTC

happens too (Alt+4 disabled in latinoamerican keyboard) in Fedora 17 x86_64 with KDE 4.10 
changing the shortcut to another combination in 
Global Keyboard Shortcuts -> Kwin  -> Walk through Windows of Current Application(reverse)
solved the problem and I can use alt-4 again to select the fourth tab in the applications

Comment 3 Jan Ritzerfeld 2013-11-24 13:26:05 UTC

Same problem with a German keyboard where '~' is AltGr++. Thus, Alt++ stops working which is used in KMail for jumping to the next unread mail.

Comment 4 Jan Ritzerfeld 2014-12-30 16:30:32 UTC

Using openSUSE 13.2 with 4.14.3, Alt++ in KMail jumps to the next unread mail again.
@David: Does Alt+4 work for you, too?

Comment 5 David Martí 2014-12-30 16:32:02 UTC

@Jan: Thank you for your interest; unfortunately I am not using KDE currently.

Comment 6 Jan Ritzerfeld 2014-12-30 17:05:02 UTC

@David: You are welcome, I accidentally hit Alt++ today and it worked. Oh, I'm sorry to hear that!
@Gabriel: Does Alt+4 work for you, now?

Comment 7 Thomas Lübking 2014-12-30 17:12:55 UTC

Just to get some confusion out of this: kwin allocates (by default) Alt+Qt::Key_AsciiTilde ("~") for tabbing, but NOT Alt+Qt::Key_Minus ("-")

That does not invalidate the general problem and I cannot say whether KWin actually has allocated Alt+Qt::Key_Minus in the past for sth. else, but I possibly you've been facing sth. else, in particular ANOTHER client (which is currently just not running) allocating global Alt+Qt::Key_Minus.

Comment 8 Jan Ritzerfeld 2014-12-30 17:41:49 UTC

@Thomas: Now I am confused. :) You are referring to which comment exactly? Because I don't see any that mentions Alt+Qt::Key_Minus ("-").

Comment 9 Thomas Lübking 2014-12-30 17:46:41 UTC

The tilde ("~") renders like an en- or em-dash here unless I increase the font (no idea what bugzilla sets there) and since the plus "+" was mentioned, I thought to better clarify this ;-)

Alt+Qt::Key_AsciiTilde is still taken by default - check "kcmshell4 keys" for the configured ./. default shortcut.

Comment 10 Jan Ritzerfeld 2014-12-30 17:50:28 UTC

Ah, okay, now I see. Indeed, using the Qt::Key enum is a good idea!

Comment 11 Patrick Silva 2019-10-31 22:27:15 UTC

Alt+~ not even works with my keyboard layout (brazilian portuguese, abnt2), nothing happens when I press it. Plasma should not have a broken shortcut by default.

Operating System: Arch Linux 
KDE Plasma Version: 5.17.2
KDE Frameworks Version: 5.63.0
Qt Version: 5.13.2