No, you aren’t understanding what I am saying. Otherwise you would know that I am right. Really though, at this point we have some people saying “it’s clearly wood”, and other people saying, “it’s clearly an oar”. Nobody is, strictly speaking, wrong in that. Perhaps the confusion is that I am speaking in shoulds, not what is. I think we can all agree on what is, but where we might disagree is in what should be.
I would add that the zoom shortcut in particular is unambiguous on a Swedish keyboard. If we all had a key like that it wouldn’t even be used as an example in this discussion. It is a confusing shortcut without that key though.
Wouldn’t that be very complicated to code for a developer? If the basekey is , (comma), shift-Command , would generate Command < on an English keyboard but Command ; on a Swedish.
I don’t see how it would be complicated, again think of (in the sense of should be) the Shift as a pure modifier, not a typing key. It doesn’t make a “;” or a “<”, just like Option-Command-O isn’t really secretly Command-ø (on my keyboard anyway).
I think this perhaps is a base part of the confusion, because as I understand it that isn’t necessarily how keyboards communicate back to the computer what character has been typed – in part to allow reprogramming keyboards, etc.
Doesn’t the keyboard just communicate “key press at such and such location?” And then it’s up to the driver software to convert that to the appropriate character? (Using the term “driver software” in the broad sense here.)
No, the key 8 hosts ( and [ which are not very significant in relation to footnotes.
That would reduce the number of available keys significantly. Only the letter keys a-z and the number keys 1-0 are universal basekeys, which would exclude 12 keys if I count correctly.
If one wants to use for e.g the keys . , - + < > ’ * one needs to use the Apple version of identifying the keys, i.e. use the actual symbols/characters and not the “basekeys” because those keys don’t have universal basekeys.
From what I understand, the keyboard itself has enough electronics to figure out which physical key(s) are pressed and send the appropriate scancodes to the computer. So a different scancode would be sent for a vs. shift-a. There’s also a difference between the “pressed” scancode and the “released” scancode – the keyboard hardware will generate a constant string of pressed scancodes when you hold a key down. Scancodes are why the computer can tell the difference between, say, left-Alt and right-Alt, or between the keypad 8 and the 8 from the top row – they generate different scancodes. It’s up to the driver to map the scancodes to the relevant characters, based on which physical keyboard you have, your language, etc.
Unless you dig down low, most programming libraries don’t really deal with raw scancodes, so you lose the visibility into the exact physical key(s) that are pressed.
Back to the original issue, that of easily and intuitively zooming a view… does scrivener support touch pad gestures? On a Mac, the fore finger and thumb pinch and un-pinch gestures have come to universally expect zoom control.
Just tested:
Cork board view doesn’t support pinch multitouch zoom, but does support two finger swipe for scroll.
It should be! You might be in the wrong context though, as that command opens the selected items in the current editor (⇧⌘O in the other editor).
If such a thing happens, it would be at a pretty high level, and probably voluntary. The tools that I have that can examine events as keycodes and such all indicate what I’ve been saying here, that d has a keycode of 7, and ⇧d also has a keycode of 7—the only important difference is that the keycode 225 (left_shift) is in a KeyDown state while the 7 Down/Up event occurs. In some cases, this condition will cause a ‘D’ character to be inserted at the cursor position, but in other cases, like in a canvas view used by a graphic design program, it might actually function as a proper shortcut.
That is closer to how I understand it. The keyboard circuit itself has its outputs mapped to keycodes which are fired off, and it is the driver that turns them into system events. The keyboard software layout (how I can apply the Swedish mapping to my US English keyboard) is a translation layer for those events into symbols—that’s where an address becomes “d” and so on. Keymapping is a layer above that, where we can say 7 should be treated as 14, and could in doing so create our own Dvorak layout or whatever. It’s one layer above that where system events are globally available to software as symbols. I believe here there is also a higher level of abstraction for programmers—in that when you write software you use symbols to communicate shortcuts in the interface builder and such, but the software itself is going to be working with events that are less abstracted.
But nowhere in any of that does Shift hold some power that causes the 4th key from the left on the 4th row down to emit a keycode other than 7. Even changing the software input layout itself does not change that. The ~/` key on my keyboard emits 53, if I apply the Swedish layout, that key becomes the >/< key, but when I press it, it is still 53. It may well be another code on lunk’s machine, that physical key is another location entirely, and my keyboard is actually incapable of expressing “<” or “>” as basekeys—those symbols do not exist at the keycode level, no more than “” has a key.
(There is one notable exception: the fn key does have the power (probably even at the hardware level) to change the underlying keycode the keyboard emits. fn↩ is a different key entirely from by itself.)
Given all of that, I would say it is better to think of shifted and meta-shifted characters as a rudimentary form of shortcut, and this shouldn’t be too surprising given that the shifted output mainly only applies, as we think it does, to a text-input contexts. Outside of the conventions of text input, ⇧L is a perfectly valid stand-alone shortcut. But an even less weird example can be demonstrated from ⌘O and ⇧⌘O. This is not ⌘o and ⌘O—at the level of driver output to the software layer, the only difference between these two chords is the addition of the 225 (or 229 which is the code for right_shift, a distinction virtually no software considers meaningful) keycode being in a KeyDown state, along with 277 or 231 (right_gui/left_gui, or “command key”) when 18 (“o”) event is registered.
But to step back to the original argument, since this has been a digression into the technical, this is primarily a display argument: how should shortcuts be communicated with the user in GUI level tools and so forth. Should every key necessary to invocation be printed?
If not, why not? To me this seems reasonable even if I’m wrong about the underlying technical components, even if ‘D’ has a physical keycode separate from ‘d’—that isn’t something the user should have to bother with knowing.
Yes, but by that same token at the level that shortcuts operate, it is only the base key that is registered. If you go into System Preferences: Keyboard: Shortcuts and create one for yourself, you will note that you get (on an English keyboard, Lunk’s cat!) ⇧⌘8, not ⇧⌘* or ⌘*. It is not actually possible, in fact, to create ⌘> as a shortcut on an English keyboard! But herein is a layer of abstraction that the Mac uses, where if you have a shortcut that is actually registered with the shifted symbol, at a high level, then it will allow Shift to be a part of the shortcut in order to invoke it—this is exactly what happens with the Zoom In/Out shortcuts on an English keyboard, even though internally, at a level deeper than the source code level, the command event is ⇧⌘,. It is the effective symbol that matters in the translation layers, as anyone using a Dvorak layout without QWERTY-on-Command settings can attest.
To clarify, I don’t actually have a problem with that approach, as it does mean localisation is easier and shortcuts are available to more people around the world. I just think they should printed accurately and completely in the localisation, that’s all. I really don’t understand why that is controversial—it certainly isn’t unusual, as I say this is how the vast majority of computers work on the planet. Macs are the weird one here.
I did not think it necessary to say out loud that I proposed that shortcut based on what happens on a UK/US English keyboard. Secondly, you handed this one to me on a silver platter! It’s almost as if we looked at a Swedish keyboard and chose the shortcut for the result you get, because I would say ‘(’ and ‘[’ are even better than asterisks! In common English usage, both are quite representative of comments (as the parenthetical is a kind of grammatical inline annotation) and referenced notes.[23] How appropriate then to attach command modifiers to these keys and make them go from printed usage to features!
Anyway…
Given the above on how Shift is actually treated as a parallel signal at all levels and typing shifted punctuation is really better thought of as a low-level text context shortcut for producing a programmed alternate symbol from a key, then what you are saying is ignoring the fact that some symbols require shortcuts to produce in the first place. Precisely which symbols require shifting, and what keys are shifted, will change from one regional keyboard to the next (again the specifics of this are not directly relevant, except to acknowledge that for some people the shortcut will be physically different), but the overall pool of available anchor points remains roughly the same—we all have about the same number of keys under our fingers. We’re just shuffling which symbols require modifier keys to produce in the first place.
That said all said, even if a key or two becomes unused for shortcuts, the Mac is in no danger of running out of possible permutations, with its four modifier keys. The actual cap on shortcuts is limited more by what contortions humans will tolerate memorising and performing.
No it does not. An algorithm for that was developed for iOS, and it works there, but it is much simpler on iOS—there are no corkboard display options that impact zooming. On the Mac there are several conditions where that gesture would not map in a meaningful way, or would produce odd effects when used. I don’t believe any of them would make it impossible to implement, but it just never happened and I’m not sure what that status is on whether that ever will be ported in.
There is a slider in the corkboard options popover, if you prefer a more fluid approach.
My misstake, they are Open in Left Editor and Open in Right Editor.
… and shuffling which symbols that don’t require modifier keys at all because they have been moved from shift/option/command state to become a basekey (like < on a Swedish keyboard), plus adding three extra letters on a Swedish keyboard which then becomes base keys that aren’t used at all as shortcuts because the developer didn’t know those keys existed as basekeys.
I still think that Apple’s solution is the smartest: show which characters that are used, irrespective of how you produce them - which combination of key and modifier.
If the Shift key had been shown in the menu shortcut for zoom, they way Randall wants them to be shown if I understand him correctly, the shortcuts would have been Shift-Command < and Shift-Command > which on a Swedish key board, where < is a basekey and > is the result of Shift < would have become really weird as there is no way to press Shift-Command > as that would require some kind of double Shift.
So the only way to solve that would be, as I suggested, to skip all keys but a-z and 0-9. But then again, if you include keyboards using other alphabets, then it gets really complicated.
I think Apple spent some time thinking about this before deciding how to do it.
Really though, at this point we have some people saying “it’s clearly wood”, and other people saying, “it’s clearly an oar”. Nobody is, strictly speaking, wrong in that. Perhaps the confusion is that I am speaking in shoulds, not what is. I think we can all agree on what is, but where we might disagree is in what should be.
I really don’t understand why that is controversial—it certainly isn’t unusual, as I say this is how the vast majority of computers work on the planet. Macs are the weird one here.
It’s almost as if we looked at a Swedish keyboard and chose the shortcut for the result you get, because I would say ‘(’ and ‘[’ are even better than asterisks! In common English usage, both are quite representative of comments (as the parenthetical is a kind of grammatical inline annotation) and referenced notes.[23] How appropriate then to attach command modifiers to these keys and make them go from printed usage to features!