Stack And tile shortcuts/improvements

Development OS
#21

I have added a section about mapping of logical moderator keys to physical keys.

Note that the mapping below is only a suggestion and open for discussion. I have no horse in this race. What is important to me is that the usage of logical shortcuts are standardized in order to avoid interference with applications, and make it more intuitive for the user.

PHYSICAL KEY MAPPING

The logical OPT, CTRL and ALT must be mapped to physical keyboard keys, or key combinations where suitable keys are missing, such as IBM Model M that only have Ctrl and Alt keys.

For "PC" keyboard with a "Win" key, OPT should be mapped to "Win", CTRL should be mapped to Ctrl and ALT to Alt.

For keyboards without a suitable OPT alternative, an alternative key sequence must be used. [Suggestions? Could CTRL CTRL work as OPT? That would be CTRL CTRL CTRL for OPT CTRL] 

Apple keyboards should map OPT to Command, CTRL to Ctrl and ALT to the Option key.
#22

That is a valid point. Since a lot of commands could be used to launch applications, even 3rd party once, the OPT key should be reserved to be defined system wide and not by any application.

Examples could be OPT SPACE that is excellent to be used to launch QuickLaunch or similar application, OPT F to open Find etc. That would mean that CTRL F would have to be mapped to an applications Find, which differs from OPT Z/X/C/V etc. That is not intuitive. Both options have their respective drawbacks.

This needs some thinking.

*insert Winnie-the-Pooh thinking*

#23

I’m not sure why you map Opt to Command and Alt to Option on Mac keyboards. I use a Windows gaming keyboard on a MacBook Pro and I map the Alt on that keyboard to Command and then the Windows key is Opt. This matches the layout of the built-in keyboard on the laptop and works really well for me. On a normal Haiku keyboard layout which is more Mac-like I think it makes sense to map things that way. Of course probably not many people using Haiku use a Mac keyboard layout.

#24

It is only suggestions, which I clearly have stated. The suggestion is based on Apples intended usage of their keyboards, where the keys are labeled “ctrl”, “alt” and “cmd” respectively (see image below). Feel free to discuss how you and others want them mapped. As I said; I have no horse in that race.

What is important is to standardize the usage of the logical modifiers. Haiku currently has no such standardization, or guideline at all. As Haiku stands today, it is impossible to add a single shortcut to the system without risking breaking applications. That is what I am trying to fix with this, and at the same time make it more intuitive and easier to use.

1 Like
#25

Personally, I feel that after 25 years of using BeOS/Haiku I’m very used to our ‘traditional’ keymappings. If we can make everything completely configurable, I’m all for it. The same for easier shortcuts for S&T (the scope of this thread), if that is possible.

But changing OPT for CMD (= ALT) to be more like a Mac, or mixing ‘system shortcuts’ (OPT) with 'app shortcuts (CMD) doesn’t make sense to me.

2 Likes
#26

Then we’ll change that. I see no problem in that. I have only followed what is labeled on the keyboards. As I have said; I have no horse in this race.

EDIT: What does “change OPT for CMD mean”? Those are two logical modifiers. The physical layout differs between a “PC” keyboard and an Apple keyboard. On an Apple keyboard, the Alt key is where the “Win” key is on a “PC” keyboard, and vice-versa.

Are you suggesting that keyboard combinations using both OPT and CTRL should be non-valid?

My reasoning behind the “rules” is that any shortcut using the OPT key is a system reserved one, and any shortcut without the OPT key is reserved for applications. That is the only rule.

All other rules are which keys should be preferred. To me that makes sense.

Currently Haiku has no rules. That makes no sense at all.

#27

No. I commented on your suggestion:

ALT C/X/V/W/Q/
 → OPT C/X/V/W/Q/
 (like on a Mac)

I understood that to have a mix of ALT-commands like ALT+O, ALT+S to open and save, mixed with OPT+C/X/V to copy/cut/paste in application menus.

#28

CMD is traditionally ALT, but can be changed to the Linux/Windows key CTRL.

#29

We need to think more about this. See my comment above.

There are two solutions to this problem, both with its respective drawbacks.

On the plus side with my suggestion is that we only need to reserve key mappings using the OPT key. All other keys are free to be used by the application. The downside is that system functions and some application functions (such as cut, paste, undo/redo, find etc) use the system key, not the application reserved key.

The down side of using an alternative key, like ALT is that we have a problem with consistency if we do not reserve some standard keys.

Both solutions have its positive and negatives. Input is appreciated.

EDIT:

So the alternative solution may be to reserve OPT for system use, ALT (without OPT OR CTRL) for “standardized” application commands (copy, cut, paste, undo/redo, find, help, print etc) and let the applications freely use the CTRL modifier.

Is that a better solution?

#30

Keep in mind that some of us (myself included) use “Windows/Linux shortcuts mode” where Cmd is CTRL and not ALT.

#31

That behavior is unchanged in my proposal. Users may remap their logical modifiers depending on what keyboard they use or their own individual preference.

2 Likes
#32

@humdinger, @X512, @leavengood, @SystemShock:

I’ve thought about your input and came up with this alternative. What do you think about it?

MODIFIER KEY RULES


The OPT modifier is reserved for system defined shortcuts and is its primary modifier. Applications may not use the OPT modifier, and system defined shortcuts must use the OPT modifier.

  OPT F -> Opens the Find system application.

The CTRL modifier is the primary modifier for application defined shortcuts. It can be freely assigned by the application.

  CTRL R -> Reload in WebPositive.

The ALT modifier when used without OPT or CTRL is reserved for common shortcuts that should be consistent thruout the system.

  ALT Z -> Undo.

  ALT S -> Save.

  ALT SHIFT S -> Save as...

  ALT F -> Invokes the application's find function.
#33

Why make difference between this two? System/application separation should be enough.

#34

Because without doing it, we cannot unify commonly used shortcuts. It’s about consistency. We do not want half the applications use CTRL Z/X/C/V/S and the other half ALT Z/X/C/V/S. That’s my reasoning behind it.

I don’t know if this is the best way of doing it, so input is greatly appreciated.

#35

Application decide use common shortcuts or not. Application can’t handle common shortcuts if it not aware of it and do not implement it. Application private shortcuts is extension of common shortcuts. If extension is handled externally to application logic, it is system shortcut, not application.

All will use Cmd (Alt) as currently done.

2 Likes
#36

OK, so just because some of this thread is hurting my brain, ya’ll’re saying:
image
I only ask because I was under the notion that Ctrl (Control) and Alt/Option were ALWAYS Ctrl and Alt, and the only outlier was Logo / Command. Historically, whereas on PC keyboards, the ❖/Logo key was shoved between the Ctrl and Alt when it was introduced, the Closed Apple/Ctrl key was cloned, shoving the ⌄Option/Alt and Open Apple/⌘Command keys to the right on Mac keyboards. From my understanding, the BeBox just used an AT/PC layout keyboard, so where does this weirdness come from?

1 Like
#37

Yeah, it’s confusing. It’s easier to just think of the logical modifier functions (CTRL, ALT, and OPT, which by the way do not make sense since OPT do not exist on a “PC” keyboard and ALT and OPT are the same key on Apple keyboards) and what they should do. What keys those are physically mapped to is just a matter of taste.

I just want to make some guidelines for it that is easy to understand, remember and creates consistency, both for users and developers. I am thinking about it and I have another alternative that I would like to present.

#38

For completeness (and to add some confusion): on keyboard layouts where there is an altgr key, the mapping is different for the left and rigot sides of the keyboard currently. This is why we don’t use the names written on the keys.

So basically, the layout is currently:

If you use a keymap with AltGr:

Control - Option/AltGr - Command - Space - Option/AltGr - Command - Control

If you use a keymap without AltGr (pretty much only US QWERTY?):

Control - Option - Command - Space - Command - Option - Control

Thefe are the default. But some people want the command key on the left, so that it behaves similarly to Windows and Linux. In this case the mapping is:

With AltGr:

Command - Option/AltGr - Control - Space - Option/AltGr - Control - Command

Without AltGr:

Command - Option - Control - Space - Control - Option - Command

In most case, the key usage likely does not match the label on the physical key. And with AltGr keymaps, keys with the same label do different things, while keys with different labels do the same thing.

Ideally we could change the way we handle AltGr and handle it really as a separate key (as it should be) and not as an option key. I think there is some work towards that in a not-yet-merged patch on Gerrit
Command

2 Likes
#39

Thank you @PulkoMandy for your input.

I think this needs more clearing up than just the shortcuts part. I mentioned all the modifier keys in my initial proposal and I would like to address some of that again, because there have been a lot of misunderstandings in this thread, which to me indicates even stronger that change is needed.

  1. Alt and Alt Gr are not the same key. Alt is an alternative key, or options key. Its intention is to be used to type in shortcuts. Alt Gr is a modifier to type in alternative graphics, iow characters. Alt Gr should not be used for shortcuts.

  2. There should be no difference between left and right modifiers when inputting shortcuts. When one hand do not reach a modifier and a key, an alternative to using two hands is to use the modifier closer to the key. For example L is to far away from the left modifiers, but very close to the right modifiers.

  3. Left and right modifiers should be separate if the applications wish to use them for other things than shortcuts. I mentioned the examples of VirtualBox and IBM terminal keyboards using the right Ctrl as a special key. Another example is pinball-type games using left and right Ctrl as flipper controls.

  4. I think I will suggest renaming what I call logical modifiers that I have taken from Haiku’s documentation, CTRL, ALT and OPT since on Apple keyboards they do not make sense. More logical would be CTRL, ALT and maybe SUP (for super). The problem as mentioned earlier is that ALT and OPT are the same key on Apple keyboards.

1 Like
#40

Yes, of course, our current situation with regard to AltGr makes no sense and this should be fixed. This is a hack we inherited from BeOS because they designed their keyboard system on keyboards without a “Windows” key (pre-1995) and then badly adapted it to the new keyboards.

I just think this situation helps understanding why we currently use key names (control/option/command) that don’t match the label on the keys - in the current situation it’s just not possible. An attempt to change the key naming without first fixing this will just result in more confusion for us AltGr users :frowning:

As far as I know in the UI and in the code we use the names “control”, “option” and “command”. But it seems the userguide team decided to use “control”, “option” and “alt”. Indeed that doesn’t help making sense of things :frowning:

If we fix the AltGr thing, we could have the UI show the actual key labels (matching the keyboard). But we can’t do that in the userguide.

2 Likes