I guess I can sum this up by saying OS X has an additional modifier key than Windows, so you basically have 33% more power right out of the gate. The "Windows Key" is nearly useless.
X Window software used to get this right, too; Unix workstations generally had another modifier (e.g. Meta, diamond on Suns) since they knew better than to hijack keys people would type in a terminal. It's only the this-is-finally-the-year-of-Linux-on-the-desktop crowd slavishly imitating Microsoft's mistakes that screwed it up.
The blame lies with "desktop environments", not X.
X has plenty of its own problems without getting Gnome's problems heaped on top.
Edit:
> It's only the this-is-finally-the-year-of-Linux-on-the-desktop crowd slavishly imitating Microsoft's mistakes that screwed it up.
Most of the recent garbage they've cargo-culted from Apple (and common software for OS X), not Microsoft. Witness the really shitty reimplementation of Growl, the really shitty (and shamefully unmandated) window menu bar -> system menu bar consolidation.
And hey, as far as ‘really shitty reimplementations of Growl’ go, even Apple has one now.
I don't agree with this at all.
I find it baffling that a company of great designers made such bad decisions about keyboard shortcuts.
Perhaps they are consistent, but they are consistently bad.
Paste and match style (incredibly useful) is "alt-shift-command-v" i.e. four keys. There are plenty of other shortcuts that also require four keys. Four is too many. Three is too many for such an important function. This is absurd.
Using shortcuts in IDEs is a nightmare on most apple keyboard. e.g. Intellij, to run your program: alt-shift-f10. This is daft in itself, but it actually translates to function-alt-shift-f10 on many keyboards. Yes, you can change your settings, but then you could remap all your keys in any O/S. Miss the function key and you've just muted your volume.
I have no interest in slagging Apple off; I use their products almost exclusively, but this is obviously an area where they messed up. I'd love to see this fixed, although I understand why they probably won't.
I really find that hard to see as anything but the IDE's fault, probably due to cross platform shortcuts not rethought for OS X - but even then, something like 40 base non-function keys times at least four combinations of modifiers, and something as important as running the program gets relegated to alt-shift-F10?
That's fine, but the IDE is an application running on the OS X platform. OS X has these problems just as much as any platform, but the situation is made worse by their use of the function keys and by poor choices for other shortcuts.
Now you could point out Pages has the same shortcut and same stupid behavior. I agree, but that's what happens when there's a clear market leader.
(Oddly enough, I've been implementing a web-based word processor, and we make paste-and-match (paragraph) style while retaining (character) styles the default. You can't actually do this in Word or Pages — default or not — despite the fact it's what users want 99% of the time. So if I paste some text with an italicized passage, the font changes to match the ambient styling, but the italics remain. When we implemented it, the UX people were flabbergasted -- they assumed it must be impossible because no word-processor does it.)
If I copy and paste from a web browser, sometimes I want the formatting and sometimes I don't. It's not an usual case. Places where I use this shortcut include Word, Evernote and Mail. It's just not a sensible key combination.
The default SHOULD be to lose the formatting of the original and to use the font/style that is in Word. I would think that 99% of time anyone is copying and pasting into Word this is their intended result.
I agree with the other post, it is incredibly stupid to have it keep formatting from the original by default.
Yes, it is. https://developer.apple.com/library/mac/documentation/UserEx... says "Table A-2 lists the system-reserved and commonly used keyboard shortcuts mentioned in the rest of this document."
Table A-2: contains ../art/ks_option_2x.png ../art/ks_shift_2x.png ../art/ks_command_2x.png V Apply the style of the surrounding text to the inserted object (equivalent to the Paste and Match Style command). See “The Edit Menu.” That links to https://developer.apple.com/library/mac/documentation/UserEx..., which describes the command, too.
I disagree with the claim that this is a bad choice, though. It may not be optimal if starting from a tabula rasa, but Apple did not do that when it introduced the combination, five years ago or so, in my memory. By that time Command-V has done styled paste for about 25 years, making it difficult to dethrone.
We must be glad that we have a standard for this, not angry that it may be a bit complex to type.
I'm suggesting the standard paste should behave as expected, not adhere to some literal definition the user doesn't care about. If I copy a passage of text from one document and paste it into another, I generally want it to look like it belongs in the destination document but I don't want to lose obvious intentional styling such as italicization.
The common case should be the easy case. Instead we have the common case and the four-fingered shortcut both doing the wrong thing. Awesome.
Maybe, the logic in a word processor should be to keep character styling, but not paragraph styling, but I think there will be many edge cases (for example, the user might be using the word processor as a document layout package)
I doubt those edge cases can be programmed away; user intervention is required. Microsoft solves that after the paste. That may be the better solution.
> Paste and match style (incredibly useful) is "alt-shift-
> command-v" i.e. four keys . . . Four is too many. Three
> is too many for such an important function.
I've literally never heard of this functionality before, in any application, on any platform. tell application "System Preferences"
activate
set current pane to pane "com.apple.preference.keyboard"
end tell
tell application "System Events"
tell application process "System Preferences"
click checkbox 1 of tab group 1 of window "Keyboard"
end tell
tell application "System Preferences" to quit
end tell
Then, put the following line into your .bash_profile. alias f12="osascript .f12Keys"
Now whenever you need to switch the default behavior of function keys, simply open a new terminal window and type "f12". It takes my computer about half a second to execute. That's kind of the brilliance of Apple products and Cocoa. If there's something you do frequently, if it's in a GUI or otherwise, so long as it's written in Cocoa you can automate it. Yeah, most Apple users have never heard of AppleScript, but for those who use it for the little things every day, it's quite helpful.I could never remember the various screen shot shortcuts, so for me it's command-escape for the clipboard and option-escape for straight to a file.
It took me less than a minute to change Pages so command-v pastes matching style, and command-option-v pastes with the original style. Even better, Pages's menus display the new shortcuts.
The latest Pages doesn't really seem to have paragraph styles vs. character styles, so it might be more difficult to pull that off, but Automator is very clever, and AppleScript moreso, so I'm betting it's possible.
The WindowsKey is often overlooked, for example, there are great key combinations for manipulating application windows. WindowsKey+Arrow moves the current window around in a logical way (up maximizes, left docks to left edge of screen, etc), WindowsKey+Shift+Arrow moves the current window to another monitor in a sensible fashion. Out of the box OS X doesn't seem to have equivalents.
On OSX, you can install something like ShiftIt, but if ANYONE discovers such a utility for Linux that is DE agnostic, I would cry with joy because I am using tile -m at the moment...
why? command-Tab (switch between and show running apps) and command-Q (force quit)
also you can use command w to close a window if really really want to go that route
Edit: Thanks arrrrg, just noticed your solution - alt command esc to reactivate the Force Quit window, then command W.
What’s not as obvious is how to close this window without the mouse when you have switched to some application and Force Quit is no longer the active window. Command-Tab won’t allow you to switch to the Force Quit window since it’s not treated as an app by OS X. However, you can switch to the window by simply using the command for Force Quit again, i.e. pressing Command-Option-Esc, then closing the now active force quit menu with Command-W.
And such dumb commands within the menus! eg. Xcode show debug area: cmd-shift-y, continue: ctrl-cmd-y; these seem stupid to me, but probably because they have repurposed the Fn keys (F1-F19) to show expose etc. instead of having real function key behaviour, and probably because some function keys are missing from the tiny wireless keyboards...
To be fair, I am perfectly used to both of them but moving from OS to OS was a horrible learning curve to begin with!
I would say that keyboard shortcuts are consistently bad across OSX but I am perfectly used to them :-)
The use of the Command key and a bunch of standard shortcuts using it are particularly notable.
#notsoobjective
If naught else, I will say that:
- The use of Cmd so widely and consistently makes it easy to bind one's own shortcuts to Ctrl/Shift/Alt/... (every menu in almost every application I use contains only Cmd shortcuts).
- The ability to remap shortcuts to anything in a menu being built into the system for all apps systemwide (System Preferences -> Keyboard) is amazing and underappreciated, methinks.
- The almost completely consistent use of a single windowing toolkit (Cocoa) everywhere makes a whole bunch of controls incredibly consistent in feel, which includes all textboxes supporting OS X and Emacs cursor movement keys, irrespective of the application - the mind boggles. o_O
- Similarly, the systemwide use of Cocoa means that the endless tools that allow for keyboard rebinding and window movement that we see (Slate, BetterTouchTool, ...) not only can exist but work very reliably and with few corner cases with most-every application on the system, oftentimes through the Assisted Access APIs (another thing Apple do well on all their platforms, I'm quite reliably informed).
OTOH, on Linux I use Xmonad as my DE and I will admit to missing the amazing keyboard-based window control I get with the tiling window manager (I use Slate on OS X for a poor facsimile to the same effect).
Well, I didn't know this was possible... and I have used Macs for a few years!
There's just no reason for Windows to be that bad.
I second the "everything is about five syllables" and sure, you can set up aliases, but I went through that hell on VAX/VMS and don't want to go back.
Plus why are all the built-in commands like 20 characters long and camel cased?
Anyway, if you have to suffer PowerShell at least do it in the ISE.
C-a is always "beginning of line" and Command-C is always Copy.
and never the twain shall meet.
(I've had issues in linux going from terminal to windows, in fact very recently I kept ^W'ing while in GUI mode)
Depending on where the control is on your keyboard (Windows vendors keep swapping FN and CTRL unfortunately, and rebinding might not be easy), I think the position of the hand is more natural - on the other hand, you might strain your pinky when pressing CTRL (or SHIFT) for long time and I haven't noticed that with using my thumb yet (and I doubt it will happen, given it is a much stronger finger).
In OSX, last time I looked (maybe a version or two ago), there was really no builtin way to achieve the same thing. Command+Space then typing what I want to open is pretty close, but way more keystrokes, and not as powerful.
It's not quite as straightforward, but you can define custom services using Automator, and subsequently bind them to any key combo using System Preferences.
Since Automator workflows can do pretty much anything (like running AppleScripts, shell scripts, manipulating other apps etc...) you're pretty much free to do what you want.
http://www.macosxautomation.com/services/learn/tut01/index.h...