Bug 377722 - [suggestion] use meta instead of alt by default in window behaviour shortcuts
Summary: [suggestion] use meta instead of alt by default in window behaviour shortcuts
Status: RESOLVED DUPLICATE of bug 399375
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.9.3
Platform: Neon Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-17 12:06 UTC by Alex
Modified: 2020-11-02 18:36 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
KWin KDE 3.5.10 (57.08 KB, image/png)
2017-11-30 11:41 UTC, Artem S. Tashkinov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2017-03-17 12:06:25 UTC
By default alt + mouse is used for window specific shortcuts (moving,resizing). But alt + mouse is used by 3D apps like blender, freecad or maya (not necessary default) to navigate viewport. My proposal is to change alt to meta as it stays unused and is somewhat system key so it will be more intuitive to use it - system key for system.
Comment 1 Alex 2017-03-17 14:18:52 UTC
I've roughly checked and gnome default setting is to use meta key to move windows but ubuntu defaults to alt for both unity and gnome not sure why. Fedora uses default meta. Can check more distros if you want.
Another app using alt+click is Inkscape to select object below.
Blender also uses alt+click for loop selection.
It's not a problem to change that shortcut especially that KDE has this setting visible without need to install any tweak. But changing default will reduce googling for first-time users.
Comment 2 Kai Uwe Broulik 2017-03-17 14:58:02 UTC
Alt+click has a decades-long tradition in KDE and other places. Apps really shouldn't be using this for anything.
Comment 3 Alex 2017-03-17 15:27:17 UTC
Yep, I'm aware of this. But I'm also aware that when more sophisticated selection is involved inside app it's most probably pretty hard to workaround this.
Next one: GIMP: alt+click show layer mask
This list is short, but can show that if you want to do some creative things you will probably have to change that shortcut inside system settings.
Comment 4 Martin Flöser 2017-03-17 15:52:33 UTC
There is a window specific rule to block shortcuts. If an app requires this: use it.

For everything else: once there is a cross desktop standard on shortcuts we might consider. But we certainly won't break everybody's habit because of apps not working.
Comment 5 Alex 2017-03-17 16:10:59 UTC
That's why I've checked and gnome 3.6 made this default that way long time ago:
https://github.com/GNOME/gsettings-desktop-schemas/commit/19fe99f2f9ed8ebc77fd28465906db33c4782604
Comment 6 Martin Flöser 2017-03-17 16:38:11 UTC
what gnome does is absolutely irrelevant.
Comment 7 Alex 2017-03-17 16:59:46 UTC
Of course, that's true. I just wanted to show reason why they did this (some apps, mostly graphic), nothing more.
I hope you get my point. As a graphic designer I'm completely unaware of ability to block shortcuts or set something inside system settings because my app isn't working.
Last app:
https://docs.krita.org/Polygonal_Selection_Tool

If you take a glimpse @ google you will find, that most questions how to disable alt+click and some how to enable it back:
https://www.google.pl/search?num=100&safe=off&client=firefox-b&q=super%2Bclick+alt%2Bclick+move+window&oq=super%2Bclick+alt%2Bclick+move+window

Anyway thank you for your point.
Comment 8 Alex 2017-03-18 09:07:42 UTC
I've started thread about this:
https://forum.kde.org/viewtopic.php?f=83&t=139423
Comment 9 Artem S. Tashkinov 2017-11-30 11:41:14 UTC
Created attachment 109127 [details]
KWin KDE 3.5.10

It's perfectly possible in KDE 3.5.10.

So, in KDE 5 this setting is no longer present? Wow. It must suck.
Comment 10 Alex 2017-11-30 12:25:14 UTC
It is present with ALT is default. You have to dig inside settings, not really intuitive to find without googling.
Comment 11 Nate Graham 2020-11-02 18:36:11 UTC

*** This bug has been marked as a duplicate of bug 399375 ***