- Shrinking Universe Mac Os 11
- Shrinking Universe Mac Os X
- Shrinking Universe Mac Os Catalina
- Shrinking Universe Mac Os Download
Shrinking PNG files with pngquant and oxipng. I usually use Squoosh.app to reduce the size of my PNGs, but in this case I had a folder with nearly 50 images in it so I wanted to do it using the command-line. Pngquant can reduce the number of colours in a PNG image, which I find makes a huge differente to the file size (also possible using Squoosh). Download macOS Catalina for an all‑new entertainment experience. Your music, TV shows, movies, podcasts, and audiobooks will transfer automatically to the Apple Music, Apple TV, Apple Podcasts, and Apple Books apps where you'll still have access to your favorite iTunes features, including purchases, rentals, and imports. Even if you don't buy a new $6,000 Mac Pro, your Mac is about to get a whole lot more powerful.Alongside macOS 10.15 Catalina, Apple unveiled a new way to design apps across all of its platforms. A Mac is designed to boost productivity both in life and work, so it is quite reasonable that some powerful applications comes with MacOS for totally free. Among these apps, there are 2 mac tools can reduce PDF file size on mac for free. One is Preview, while the other one is Colorsync. #1 Reduce PDF File Size on Mac Free with Preview. Either way, Win kicked Mac in the networking jimmies, really, really hard, and Mac would not do any different until OS X. Back when Mac OS 8 was released, Apple took out a two page magazine ad to.
Nearly three years ago, Daring Fireball's John Gruber wrote an excellent article about anchored and unanchored selection in Mac OS X, titled 'Highly Selective.' (For definitions of anchored and unanchored selection, please refer to his article.)
Sadly, three years later, things are still a total mess in Mac OS X, even when one keeps the focus exclusively on Apple's own software applications. If anything, it has become even more complex and confusing.
Consider what happens, for example, if you happen to switch from the mouse to the keyboard during the selection process.
In several of Apple's text editors or applications with text editing tools (probably all based on the same underlying text editing engine), including Mail, TextEdit, but also Pages, Excel, etc., there is a total disconnect between the orientation of the mouse selection and the orientation of selection expansions with the cursor keys.
Take, for example, this sample paragraph of text in Pages:
If I now take my mouse and click at the beginning of the second sentence and drag my pointer to the right, I will create a text selection: Hyper beat engine mac os.
What if I overshot by one character or two and actually only wanted to select the first two words? To me, since the selection with the mouse was made from left to right, intuitively I should be able to shrink the selection by one or two characters by pressing shift-Left a couple of times on my keyboard.
Alas, that is not what happens. If I pressing shift-Left a couple of times, I get this:
Instead of shrinking the current selection by two characters from the right, Pages actually expands my selection by two characters from the left. In other words, it completely ignores the initial direction of my selection with the mouse (from left to right). To me, this seems to indicate that it's an unanchored selection.
But unlike a 'pure' unanchored selection (as per John Gruber's definition), this is not a selection that 'never shrinks.' If I now press shift-Right a few times, instead of expanding the selection to the right, Pages actually shrinks the selection from the left:
It gets even more interesting. The effect of the shift-Right and shift-Left shortcuts on this selection actually depends, not on the direction of the selection with the mouse (which Pages completely ignores), but on which of the two keyboard shortcuts is used first.
If shift-Right is used first, then Pages starts expanding the selection to the right:
After that, shift-Left can only be used to shrink the selection from the right:
It can no longer be used to expand the selection to the left (unless you go all the way and deselect the initial selection altogether and then continue in the other direction).
I find this behaviour rather weird, and difficult to get used to. It means that if, when using my mouse pointer from left to right to select a text string, I overshoot and want to shrink the selection by one or two characters, I first must expand the selection by hitting shift-Right once, and then I can use shift-Left Spaceinvadersclone mac os. to shrink the selection.
Having to expand a selection first in order to shrink it is rather, shall we say, counterintuitive.
But I suppose that Apple's engineers thought long and hard about this one and decided that this was the best possible compromise. (I do wonder what they call it, because it's obviously neither an anchored selection nor an unanchored one. Is it a 'smart unanchored' selection? It depends on your definition of 'smart,' I suppose…)
My real problem, however, is with the fact that this behaviour is not applied consistently throughout Apple's Mac OS X applications. For example, I would argue that, when you select an item in the Finder and make its name editable, you effectively open a small text editor, where you can use both the mouse and the keyboard to create selections of words or characters.
Shouldn't these text selections work the same way as in Pages, TextEdit, etc.? But they don't. Text selections in file names in the Finder (and in text fields in dialog boxes) use the old anchored selection scheme, where the direction of the shrinking/expanding, either with keyboard shortcuts or with the mouse, depends on the original direction of the initial selection.
And what about selections in lists of stuff? Which logic should they follow? Why not follow the same logic as with text selections in Pages?
Sleep escape mac os. Take a selection in the message list in Mail, for example. Let's say I use my mouse to click-and-drag vertically from top to bottom in order to create a selection of messages:
If the text selection logic described above for Pages was applied here too, the behaviour of the shift-Up and shift-Down shortcuts should work the same way as the behaviour of the shift-Left and shift-Right shortcuts in Pages.
I should be able to expand and shrink the selection, and the starting point of the expanding/shrinking would depend on which keyboard shortcut I use first. But that is not the case. In this situation in Mail, regardless of which keyboard shortcut I use first, Mail shrinks/expands the list from the bottom, which is the behaviour of an anchored selection:
Of course, to make matters worse, there are other contexts very similar to the message list view in Mail where the behaviour is yet again different. In iTunes, for example, if you create a continuous selection of tracks with the mouse by clicking on the first one and then shift-clicking on the last one, the behaviour of the shift-Up and shift-Down shortcuts after that follows the description provided by John Gruber for his definition of the unanchored selection, i.e. they can only be used to expand the selection from the top (shift-Up) and from the bottom (shift-Down).
On the other hand, selections of table cells in Numbers behave the same way as selections in Mail's message list, i.e. as anchored lists.
It's all rather frustrating, I find. And it gets even worse when you add third-party applications to the mix, which bring their own idiosyncratic ways of handling selections.
The bottom line is that, not only is the logic of the Pages behaviour described above difficult to get used to, but on top of that you shouldn't get too accustomed to it, because it does not apply consistently to all Mac OS X applications. And it is essentially impossible to predict which behaviour will apply. You are just supposed to know that, in Pages, TextEdit, the message editor in Mail, etc. it works this way, and in text input fields, the message list in Mail and tables in Numbers it works that way, and in the track lists in iTunes it works yet another way.
Will we ever get a computing environment where all selection-related behaviours are predictable and easy to absorb and get accustomed to? By the looks of it, it won't happen in my lifetime.
Shrinking Universe Mac Os 11
Since my original post on this topic has been Daring-Fireballed, has generated a fair amount of feedback, and has been followed by another post on Daring Fireball, I thought I should clarify a few things.
First of all, I want to stress that my initial post raised two clearly separate issues. One is the logic behind the behaviour that I described as 'smart unanchored selection' (for lack of a better term) and the other one is the inconsistency across Mac OS X applications.
The first issue (the logic behind) has generated a variety of responses. Both John Gruber and Dmitry of Coding Robots provide an explanation for the behaviour, which is essentially that text selections made with the mouse are unanchored, i.e. their behaviour does not depend on whether you clicked and dragged from the left to the right or from the right to the left.
The one important point to note is that, when selecting with the mouse, you can actually select text without going either from the left to the right or from the right to the left. A double-click on a word will select that word, and, as Dmitry rightly argues, such a selection has no direction, so there is no apparent reason to give a predetermined anchor to the selection.
Shrinking Universe Mac Os X
Similarly, a triple-click on a paragraph selects the entire paragraph. Here again, there is no way for Mac OS X to determine a direction for the selection based on the user's actions.
Possibly because of these situations where the direction of the selection with the mouse is undefined, Apple has adopted HIG guidelines for extending text selection with the Shift and arrow keys, whereby any selection with the mouse is effectively unanchored and the direction of the extension is determined by the first keyboard shortcut used after selecting with the mouse.
I don't necessarily agree with this choice, because I think that, in cases where the user clicks and drags (instead of double-clicking) or double-clicks and drags (instead of triple-clicking), there is clearly a direction to the selection. I would also argue that it is easier to be more accurate with the click before the dragging than with the mouse button release at the end of the dragging. Dragging is an operation that creates tension in the muscles of the hand and, in my opinion, reduces the accuracy of one's movements. Because of this (although I obviously don't have hard scientific evidence to back it up), I believe that users are more likely to make a error (to go too far or not far enough) with their selection at the end rather than at the beginning. And that's why I find it a bit difficult to adjust to the idea that even selections with clicking and dragging are unanchored.
The other point is that making the selection unanchored is not the only alternative when the mouse selection is direction-less (i.e. when the user's actions do not indicate a direction). Even though double-clicking on a word does not indicate a left-to-right direction for the selection, it can be reasonably assumed, in a left-to-right written language such as English or French, that the user is more likely to want to extend his selection to the right than to the left. How often do you double-click on the last word of a phrase and then proceed to work you way back to the beginning of the phrase? I sure don't do that every often.
That said, in my original post I clearly said that I was willing to believe that Apple's engineers had thought hard about this issue and decided that the 'smart unanchored' behaviour was the best compromise in the circumstances—which the HIG guidelines appear to confirm. So I wasn't really 'complaining' about their choice (contrary to what John Gruber and Dmitry say). I was just saying that I found it somewhat difficult to adapt to and was not entirely convinced it was the right choice.
What I was really complaining about is the second issue, i.e. the inconsistency. What the Apple HIG guidelines don't tell you is that some of Apple's own applications do not comply with the guidelines. Text selections in a file's name field in the Finder do not work that way, and neither do text selections in iTunes. (They are both anchored.)
Dmitry explains that it is probably a Cocoa vs. Carbon issue. Well, I don't care. I don't think the user should have to put up with two different behaviours depending on whether the application is a Carbon application or a Cocoa application. We have had enough of these engineering issues interfering with the usability of Mac OS X applications. If Apple has defined guidelines, then it needs to update its own Carbon routines to make them comply with the guidelines as well. Otherwise, we'll still have to wait many years until all traces of Carbon are eliminated from Mac OS X (if they ever are).
Shrinking Universe Mac Os Catalina
And what makes the consistency issue worse is that the 'smart unanchored' selection behaviour does not extend to selections of items in a list. Why? I do realize that there is no equivalent of word selection (with a double-click) or paragraph selection (with a triple-click) when selecting items in a list with the mouse. So there is no purely 'direction-less' selection with the mouse (except for a single click to select a single item).
For consistency's sake, I feel that extending selections in lists should work the same way as extending selections in texts in Cocoa applications.
And there is simply no excuse for having an anchored selection in Mail's message list and Numbers tables and an unanchored selection (which is yet another behaviour, different from both the anchored selection and the 'smart unanchored' behaviour) in iTunes track lists and lists of files and folders in the Finder.
Again, it appears to be a Cocoa vs. Carbon issue and again, I don't care. I want consistency across all applications.
Of course, as I said in my post yesterday, when you had third-party applications to the mix, things can get even worse. Can you believe, for example, that it is still impossible to use the Option key with Shift and the arrow keys in Adobe InDesign for word-by-word selection? You have to use Command with Shift and the arrow keys in that application.
Shrinking Universe Mac Os Download
So good luck achieving consistency when you have developers like Adobe and Microsoft still playing such an important role in the Mac industry.
Finally, just for fun, one more thing. If you really want to see a selection-extending process gone crazy, look no further than iTunes's album view. Go to iTunes, switch to album (grid) view, create a selection with the mouse, and then try extending that selection with Shift and the arrow keys.
It's so ridiculous it's hilarious. (Thanks to Adobe Gripes for the tip.)
