New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CTRL + ALT sequence should not be used in shortcuts #2979

Closed
JakubValtar opened this Issue Nov 21, 2014 · 8 comments

Comments

Projects
None yet
2 participants
@JakubValtar
Contributor

JakubValtar commented Nov 21, 2014

On my keyboard layout (default Czech layout), I use RIGHT ALT to write special symbols. RIGHT ALT is interchangeable with CTRL + LEFT ALT. So, if I want to write {, I have to press RIGHT ALT + B, alternatively CTRL + LEFT ALT + B. Lot of symbols used in programming, such as \|[]#&@{}<> are witten exclusively using one of these combinations. Everytime I want to write }, I also get a dialog window for new tab, since they share the shortcut CTRL + ALT + N. To say the least, it makes the Processing editor unusable with my keyboard layout.

To avoid these problems, CTRL + ALT shortcuts should not be used with letters of the alphabet or numbers since they are used to input characters or there should be a way to disable or modify these shortcuts.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 22, 2014

Member

Sounds like 'new tab' had been broken and now that it's fixed, it's causing a problem.

So what's the shortcut for next/previous tab in Chrome or any others on your machine? This is just one more example where we are using shortcuts from other established software in an attempt to avoid issues like this.

Member

benfry commented Nov 22, 2014

Sounds like 'new tab' had been broken and now that it's fixed, it's causing a problem.

So what's the shortcut for next/previous tab in Chrome or any others on your machine? This is just one more example where we are using shortcuts from other established software in an attempt to avoid issues like this.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 22, 2014

Member

Hold on, though—new tab should be ctrl-shift-n, not ctrl-alt-n. That might just be a simple regression.

The only place where we use alt is ctrl-alt-left and ctrl-alt-right, for prev/next tab.

Member

benfry commented Nov 22, 2014

Hold on, though—new tab should be ctrl-shift-n, not ctrl-alt-n. That might just be a simple regression.

The only place where we use alt is ctrl-alt-left and ctrl-alt-right, for prev/next tab.

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Nov 22, 2014

Contributor

There is ctrl-alt-F mapped to "Use Selection for Find", I think it's not working, but better check.

Keys like Ctrl-alt-arrows are no problem, they are not used to input characters. I use Eclipse for coding and the only problem I have is ctrl-alt-G mapped to some kind of search, so I always unbind it when setting up my workspace.

Wikipedia has a good explanation:

QWERTZ keyboards usually change the right Alt key into an Alt Gr key to access a third level of key assignments. This is necessary because the language-specific characters leave no room to have all the special symbols of ASCII, needed by programmers among others, available on the first or second (shifted) levels without unduly increasing the size of the keyboard.

So Ctrl-Alt (= right Alt) accesses third level of key assignments, like Shift accesses the second level.

Here you can see my layout, blue color indicates third level.

Czech layout
You can see more layouts used throughout the central and eastern Europe on QWERTZ wiki page, most of them use third levels. More info on Alr Gr wiki page.

Contributor

JakubValtar commented Nov 22, 2014

There is ctrl-alt-F mapped to "Use Selection for Find", I think it's not working, but better check.

Keys like Ctrl-alt-arrows are no problem, they are not used to input characters. I use Eclipse for coding and the only problem I have is ctrl-alt-G mapped to some kind of search, so I always unbind it when setting up my workspace.

Wikipedia has a good explanation:

QWERTZ keyboards usually change the right Alt key into an Alt Gr key to access a third level of key assignments. This is necessary because the language-specific characters leave no room to have all the special symbols of ASCII, needed by programmers among others, available on the first or second (shifted) levels without unduly increasing the size of the keyboard.

So Ctrl-Alt (= right Alt) accesses third level of key assignments, like Shift accesses the second level.

Here you can see my layout, blue color indicates third level.

Czech layout
You can see more layouts used throughout the central and eastern Europe on QWERTZ wiki page, most of them use third levels. More info on Alr Gr wiki page.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 22, 2014

Member

Totally understand the problem—I try very hard to avoid using the ctrl-alt thing anywhere. We've been at this project since 2001 and our audience has always been international, so we're well aware of the problem.

Here are the issues:

  1. Again, if Ctrl-Alt-N is being used for 'new tab', that's a regression introduced in a pull request incorporated this past weekend. It should be Ctrl-Shift-N.
  2. If Ctrl-Alt-Left/Right (the only place I was aware we were using alt) are also a problem, I'm asking what's used in their place on your system. (Sounds like it's not a problem, so we can ignore it.)
  3. "Use selection for find" comes from the Mac, which uses Cmd-E (equivalent to Ctrl-E). But because we use E for export, the submitter of that patch used Ctrl-Alt-F. We can either remove the shortcut altogether, remove it on non-US keyboards, or find another unused key for it.
Member

benfry commented Nov 22, 2014

Totally understand the problem—I try very hard to avoid using the ctrl-alt thing anywhere. We've been at this project since 2001 and our audience has always been international, so we're well aware of the problem.

Here are the issues:

  1. Again, if Ctrl-Alt-N is being used for 'new tab', that's a regression introduced in a pull request incorporated this past weekend. It should be Ctrl-Shift-N.
  2. If Ctrl-Alt-Left/Right (the only place I was aware we were using alt) are also a problem, I'm asking what's used in their place on your system. (Sounds like it's not a problem, so we can ignore it.)
  3. "Use selection for find" comes from the Mac, which uses Cmd-E (equivalent to Ctrl-E). But because we use E for export, the submitter of that patch used Ctrl-Alt-F. We can either remove the shortcut altogether, remove it on non-US keyboards, or find another unused key for it.
@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Nov 22, 2014

Contributor
  1. This one is clear.
  2. As I said, UP, DOWN, LEFT, RIGHT do not have third level and can be used with Ctrl-Alt shortcuts. What I often use in Eclipse is Alt+UP or Alt+DOWN to move selected line(s) up or down, and Ctrl+Alt+UP and Ctrl+Alt+DOWN to duplicate selected line(s) up or down.
  3. I don't use many shortcuts and don't have a preference for these. I guess "Use selection for Find" will be used more often than export, so it would make sense to adhere to system standards and leave Cmd-E as "Use selection for Find" and use something else like Ctrl-Shift-E for export. I wouldn't remove it just on non-US keyboards, people sometimes switch local and US keyboard layouts on the fly and having two different sets of shortcuts for different layouts doesn't seem right. Either way, I can't code without Ctrl-Alt-F (which is [) so it would be preferrable to remove the shortcut, if it's not possible then there has to be an option to rebind it or disable it.
Contributor

JakubValtar commented Nov 22, 2014

  1. This one is clear.
  2. As I said, UP, DOWN, LEFT, RIGHT do not have third level and can be used with Ctrl-Alt shortcuts. What I often use in Eclipse is Alt+UP or Alt+DOWN to move selected line(s) up or down, and Ctrl+Alt+UP and Ctrl+Alt+DOWN to duplicate selected line(s) up or down.
  3. I don't use many shortcuts and don't have a preference for these. I guess "Use selection for Find" will be used more often than export, so it would make sense to adhere to system standards and leave Cmd-E as "Use selection for Find" and use something else like Ctrl-Shift-E for export. I wouldn't remove it just on non-US keyboards, people sometimes switch local and US keyboard layouts on the fly and having two different sets of shortcuts for different layouts doesn't seem right. Either way, I can't code without Ctrl-Alt-F (which is [) so it would be preferrable to remove the shortcut, if it's not possible then there has to be an option to rebind it or disable it.
@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 24, 2014

Member

@REAS @shiffman Any thoughts here on the third point?

"Use selection for Find" is typically Ctrl-E, but we use it for export. Originally, applet export was ctrl-E, application was ctrl-shift-E. When we dropped applets, we made ctrl-e the default for export application. We could go back to ctrl-shift-E as export application, and make ctrl-E into "Use selection..." Then again, editors like Sublime Text use Ctrl-E and Ctrl-Shift-E for "Use selection for find" and "Use selection for replace".

Member

benfry commented Nov 24, 2014

@REAS @shiffman Any thoughts here on the third point?

"Use selection for Find" is typically Ctrl-E, but we use it for export. Originally, applet export was ctrl-E, application was ctrl-shift-E. When we dropped applets, we made ctrl-e the default for export application. We could go back to ctrl-shift-E as export application, and make ctrl-E into "Use selection..." Then again, editors like Sublime Text use Ctrl-E and Ctrl-Shift-E for "Use selection for find" and "Use selection for replace".

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 24, 2014

Member

Fixed the base problem (the first item), the second item sounds like not an issue, and I'll open a separate issue for the third item.

Member

benfry commented Nov 24, 2014

Fixed the base problem (the first item), the second item sounds like not an issue, and I'll open a separate issue for the third item.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 24, 2014

Member

Moving the discussion to #2985

Member

benfry commented Nov 24, 2014

Moving the discussion to #2985

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment