Hacker News Reader

Comment by xtracto | Hacker News Reader

The problem with all these Linux/BSD attempts at mimicking the Mac is that due to the nature of the open source components, they are mostly able to mimic the "look" but never the feel.

The one thing that makes OSX different even from Windows is the way it "feels" when you are using it. And the simple things you can achieve in a very simple and intuitive matter.

I just stumbled upon an example some days ago, when I needed to add a screenshot image to a PDF. It was surprisingly easy in the Mac: Double click the PDF to open it in preview, double click the image to open it in preview and then drag the file icon of the image into the pages view of the PDF. And the image is inserted as a page in the PDF without any issues.

To do that on Windows or Linux (I use Mint in my PC) I think I'll have to print the Image as a PDF and then use some other software to "stitch" the two files together.

And like that there are a lot of other UX small things that make for a more pleasant experience in the Mac, particularly for end users.

View on HN

My favourite small detail on the Mac, is how the clipboard interacts with the filesystem. You can select some text, drag it into the Desktop and it will become a .Clipping. Now, if you drag and drop that clipping into a text field (e.g. textedit), it will be as if it was pasted.

KDE used to work like that too.

It still does.

This is certainly true for data types that the system knows how to serialize and deserialize, but (at least back when clippings were introduced) for others, the app that owns the clipboard data must provide the hook for the serialization and deserialization. Back in my first programming job, we were about to ship a shrink-wrapped software product that I will not name but you’ve almost certainly used, and we discovered that we “needed” to support clippings or else (I can’t remember if this was some Apple compatibility rule or some marketing person’s rule). We didn’t have much time, and we also didn’t have serialization code for this very complicated data structure that was on the clipboard, and my manager told me to just implement it by sticking THE POINTER in the clipping. I objected and was overruled. I did it, it shipped that way, and I will always be ashamed. You could only use a clipping in the same process that created it. I had to add code on the deserialize that checked to see if the pointer was valid. It still makes me sick to think about.

That’s the practical approach .. and you are lucky to have a manager who is technical enough to make suggestions like that

There is nothing practical about writing a pointer value to a file. This was a quick hack that made the feature appear to work rather than actually work. It's really bad engineering.

I agree with you, before the external constraints enter the picture. But as you said, it had to be delivered with this feature on a shorter timeline than a better solution allowed for. The choice between delivering something and delivering nothing, how do you proceed there?

Slip it or cut it. Doing it in a way that loses data for users is a bad call.

Sort of reminds me of Plan 9, with the ability to treat text as executable, where execution can include opening a file in a designated application. I haven't used either OS for more than a cumulative 10 minutes, but this was definitely my favorite part of Plan 9.

You can play with a user space port called plan9port (https://9fans.github.io/plan9port/) where you can run the "plumber" executable, edit your rule file and then just invoke the plumb command with some text and context and have it do things. It also comes with the acme editor and other tools.

This way you can have some of the fun of plan9 but keep your modern amenities such as wifi, a browser and whatnot.

Text isn't executable in plan 9 but it plays a major role in the design of how you interact with the system.

The functionality you describe sounds like a mixture of Acme(1) text editor and the plumber(4) file server.

Acme editor allows you to exec highlighted text so long as the highlighted portion is a valid command string. For example: if you wanted the date printed in the Acme window from date(1) all you do is type <date, highlight it, middle click it, and date's stdout is redirected into the editor and the highlighted text is replaced with the output of date. Without the '<', the output would redirect to a new window. You can also put commands into the tag bar and right click them to execute. So when I'm writing plan 9 programs, I put mk into the tag bar of the programs directory and just click mk. Of course Acme works hand in hand with the plumber and you can send plumb messages from Acme too. Right clicking text in Acme plumbs it.

The plumber is a really neat program. All it does is listen for messages that are plain old text, tries to match the message to a rule, and that rule has an associated action. You load the rules by simply copying the rule file to the plumber rule file. So for example, you send a url to plumber, it's rule looks for http://, matches it to a rule that says open mothra or netsurf and use the url as an argument and the website open in the browser. If you're inside acme and right click a header file in acme, plumber then just tells acme to open that file (assuming acme is in your rules file for text)

Do you know of a good video of this in action? I've managed to get a much better handle on smalltalk and slime by watching videos of people using them, but I dunno where to find one for acme (I looked, the ones I found didn't quite help me get my brain around it).

https://www.youtube.com/watch?v=dP1xVpMPn8M

This is also why Mac apps built using frameworks other than Cocoa (or Carbon) never feel quite right!

Sure, you may have recreated the copy and paste menu so it looks and feels identical. But did you remember to handle .clipping files? What about File > New From Clipboard? What about the system-wide custom keyboard shortcuts? Oh, and don't forget to make it all behave properly with Voiceover!

This is why it sucks so much that many important "apps" are electron shells.

Advocates of Electron sometimes claim that it unifies the look of the application across platforms. This should not be a goal. Most people are far more like to use several applications on one platform than use one application on several platforms. It is the platform that the apps should be conforming to, not themselves.

Exactly why I prefer Seaglass over Element for Matrix chat, even though Seaglass hasn't been updated in a while. Same with Telegram Desktop and Telegram for macOS.

I have yet to find a Telegram client that is a good Mac citizen :/

This isn’t true, the reason devs use Electron is for market share not some design-usage principle.

This isn’t true either. If market share is your goal, just write 3 native apps. No, devs choose electron to speed up development of apps that need to be cross-platform. They only write one app instead of three. Faster dev cycle. In doing so, they aim for the middleground UX between all the platforms and end up with something that kinda sucks on each one. Its a tradeoff that is usually overlooked, and indeed is often sold later as “a unified look”, which doesn’t do anything for typical users that work within a single platform.

Yes, but sometimes you're not in a position where your users are willing to tolerate "we cut corners to save time and money so your experience is worse as a result".

Which part are you saying isn't true? That Electron advocates sometimes claim that, or that applications should conform to the OS they're on?

Windows had a very similar idea to that, called "shell scraps" [1]. The feature was removed because basically nobody ever used it (and it was a vector for viruses) [2].

[1] https://en.wikipedia.org/wiki/Shell_Scrap_Object_File

[2] https://docs.microsoft.com/en-us/previous-versions/technet-m...

KDE's Plasma Desktop allows you to do this. You can drag text from any app to the desktop, and it will turn it into a Note.

You can right-click and paste, or Ctrl+V, on the desktop or the file manager, too, and it will save your clipboard contents as a file for you.

Same thing works for images, videos etc.

Now copy and paste that file into kedit or kword.. what happens?

I just dragged a text file into Kate and Kate opened it.

Ah yeah, text clippings are an amazing feature. The feature was added in 1994, for System 7.0 or newer[0]. Super useful. I used to be in the midst of a conversation with someone on Hotline and want to save a snippet of text. Select it, drag to desktop, done. Saved for later as a file I can refer to or even drag & drop to some other program.

[0] http://asa.max1zzz.co.uk/English-North_American/Macintosh/Sy...

> And like that there are a lot of other UX small things that make for a more pleasant experience in the Mac, particularly for end users.

There are also a lot of bugs and inconsistencies in the Mac UX that make it very annoying to use. A few that I have to deal with on a regular basis:

- App doc will randomly break - either it will not auto hide, or it will not show when pushing cursor down.

- For some reason the OS needs to disable/reset all displays multiple times in order to redetect external monitors. Not only can the monitor detection take a few minutes, but it often messes up window/workspace positions.

- You cannot drag fullscreen windows from one monitor to another. You cannot drag a non-fullscreen window to a monitor which has a fullscreen window.

- Audio will inconsistently switch between native speakers and HDMI, completely ignoring user's manual override.

- Windows will randomly disappear - app is still running and shown in doc bar but you cannot alt/command-tab to the window, or show the window from doc bar.

-Top bar will randomly not auto-hide, and/or not show when hovering.

Mac OS UX is far from any kind of golden standard fanboys try to make it out to be.

I'm more or less forced to use windows or mac for work (mac happens to be the lesser evil), but my personal debian pc is so much more intuitive, consistent, and stable.

"You cannot drag fullscreen windows from one monitor to another."

Sure you can. Use whatever shortcut you'd like to get into Mission Control, drag and drop that "Space" from one monitor to the top bar on the other.

Ahh so you are the one who uses mission control.

Cmd-Opt-D to show/hide Dock btw, if you didn't know that. Can be handy to know for those weird cases where it's not showing/hiding as it should. May or may not help with this particular case you're seeing though, but give it a try!

> Mac OS UX is far from any kind of golden standard fanboys try to make it out to be.

Haters pointing out a few flaws (which it does indeed have) doesn’t invalidate the fact that it’s still better than Windows or most Linux UIs.

> Haters pointing out a few flaws (which it does indeed have) doesn’t invalidate the fact that it’s still better than Windows or most Linux UIs.

I agree that it's marginally better than Windows, but it's inferior to Linux given the fact that you can have a superior UX on Linux. Obviously this is based on my personal preferences.

Not to mention, there's no walled garden of applications on Linux. While the "free for all" aspect of applications may be scary for some, the "welcome to adulthood, now make your own decisions" is a welcome change for many. Again, this is my personal opinion.

An issue I see with this is that not everyone has the time or will to customize their OS to their specific needs. In this regard, it might be arguable that Apple has done a reasonably good job at advertising/showcasing the ease of use of macOS out of the box.

Can I add one to your list. You can't lock the screen with the keyboard shortcut while in Expose.

> For some reason the OS needs to disable/reset all displays [...]

Yes, I hate this. Also, many monitors do not like whatever the Mac is doing, and will tolerate it only a small integer number of times before you have to interrupt power to them for a reset.

> You cannot drag fullscreen windows from one monitor to another. You cannot drag a non-fullscreen window to a monitor which has a fullscreen window.

I was actually replying to insist that you can, but then I realized (just now) that you said "monitor", not "desktop", so I'm not sure that this would work. Does it work for you with desktop spaces? 'Cause it does for me, although it makes the incoming window a chromeless as well and tiles with the existing window, which I didn't really expect.

> You cannot drag fullscreen windows from one monitor to another. You cannot drag a non-fullscreen window to a monitor which has a fullscreen window.

I think that there's a concept that just doesn't click with you (which is okay), but it does click with me.

There's actually no "fullscreen window". If you make an app fullscreen, the app creates a new "screen" (for lack of better terms, maybe it's called a Space?). The app and the screen are now one.

You can't drag a fullscreen window from one monitor to another, because there's no window for you to drag. You can only drag the whole screen (in Mission Control).

You can't drag an actual window to a fullscreen screen (eeh), because that screen is an app and is not supposed to contain any windows.

This feels intuitive to me, I use it with joy and I miss this concept badly when using various Linux DEs.

(the other stuff you mentioned are real bugs that can sometimes happen, yes, no problem with that -- but I've also had plenty of those in Ubuntu and others)

Eh, that's a lot of extra steps and complexity for no apparent reason. Virtual desktops, supported by many linux UXs for a long time, provide essentially all of the same functionality without the extra mental overhead of having to deal with 'mission control' and thinking about monitor vs space vs window, or thinking about 'which state is my window in?'.

> You can't drag a fullscreen window from one monitor to another, because there's no window for you to drag.

But you do get the window bar on hover, which is the same 'control' you use for dragging non-fullscreen windows... the fullscreen window is still a window, except it's controls have been restricted and behaviour modified to prevent it from acting as a window for no apparent reason. The way this concept is implemented in macOS is just ugly imo.

> And like that there are a lot of other UX small things that make for a more pleasant experience in the Mac, particularly for end users.

Completely disagree. Yesterday I had to figure out how to display hidden files in finder. I had to google it // apparently there is some hidden key sequence of command option control alt hell that toggles it. It is not exposed in menus anywhere and there shortcut it not all obvious. So next week I’ll be googling it again.

Contrast that with most linux UIs and even Windows. Context-menus display all possible options (generally)... nothing is hidden from the user.

Most of my gripes about MacOS have to do with the finder and context menus. They suck.

This is one example of many.

“I had to figure out how to display hidden files in finder.”

Displaying hidden files is not generally an end user feature.

As a user I would like to be able to attach my .vimrc, .bashrc, etc to emails to colleagues so they can see what I have in my settings.

In general, end users don’t even have a .vimrc, .bashrc, etc. If you even know these things exist, you’re an exception.

True. Most users will have a .emacs file.

Mac installs vim and bash by default but seeing their configuration files in Finder is spooky and not normal? It's not a terribly convincing argument that there should be no context menu in the Open File dialog window for showing/hiding hidden files.

Well, they switched to zsh, but yeah.

There is no GUI version of Vim or Bash provided. They are expected to be used via the command line, where hidden files can be seen just as they can on any other Unix.

What fraction of Mac users do you think have every used vim or bash, let alone even opened Terminal.app? Or even know that it exists?

As a Mac user who uses command prompts all day every day, I don't open Terminal.app.

I have often wished there was a way to set certain dotfiles to be unhidden, without hiding everything. It could be done with extended attributes (which can already be used to hide a non dot file, this would just be the reverse).

I don't think this would be an overly severe UNIX violation? Dot files would still be hidden by default, the extended attribute would just be an override.

Yeah this is a poor adaptation of unix software to macOS. Those tools ought to have their config files either moved to or symlinked into ~/Library/Preferences with non-dot-prefixed names in order to make sense on the Mac. It's a shame even Apple's ports don't do this.

As another comment just made points out, this is not something the vast majority of Mac users will, or should, be doing. For the rest of us, we're likely to be doing it often enough to remember the shortcut — it's second nature to me now.

The big problem is discoverability, as you imply.

> all possible options ... nothing is hidden from the user

This is the key bit. Showing all possible options would go utterly against the mac ethos.

Not only that, it is begging for people to shoot themselves in the foot (and later call techies to fix their broken computer with no idea what they did).

You can enable it system-wide with a defaults setting. Most devs I know do.

Most end-users don't know what a hidden file with a `.` is, would never create one, and don't particularly care for that level of clutter in a directory.

Isn’t the keyboard shortcut somewhat mnemonic? ⌘⇧.

What about that shortcut is mnemonic?

The command to show dotfiles is the two most commonly used modifier keys, plus a dot. If you told someone the shortcut was mnemonic but didn't tell them the specific keystrokes, they'd probably be able to guess with a minute or so of experimentation.

On a Mac invisible files aren't important for even a "pro" user... except for occasional developer needs. It worth saying a feature like this doesn't come without cost.

Progressive disclosure and a bullet proof user environment are core user concepts on MacOS. In MacOS a user can rearrange nearly every file visable to them, and never break anything.

Windows and Linux clutter up the users environment with files that literally no one will ever care about (1000 library modules and asset files for a binary application?). And yet they are less flexible to user choice. Move application out of the Application folder... boom! Pathing all breaks. Do the same on MacOS no problem.

The shortcut for toggling display of hidden items in Finder is `Command + Shift + .`. But you're correct that it's not documented anywhere which is a big point of frustration. There's tons of incredibly useful undocumented macOS features.

My sense is that theming like this is generally not aimed at people who would use a Mac in the first place, but rather BSD users who want something that looks more pleasant than their default window manager.

Creating a coherent visual language from scratch is a huge undertaking, and requires a certain skill set. Mimicking an existing design system is much more straightforward, even if the results are uneven.

From the page itself, it clearly aims at people migrating from a mac:

> It is intended as a system for “mere mortals”, welcoming to switchers from the Mac.

> I just stumbled upon an example some days ago, when I needed to add a screenshot image to a PDF. It was surprisingly easy in the Mac: Double click the PDF to open it in preview, double click the image to open it in preview and then drag the file icon of the image into the pages view of the PDF. And the image is inserted as a page in the PDF without any issues.

That is a great use case!

And screenshots on mac are, IMHO, hard to use.

The screenshot UI is frustrating, where to save to is under options, you cannot preview your screenshot, you cannot annotate the screenshot (something I do all the time on Windows), and having to choose between saving to file or clipboard is annoying.

I wanted to record video, which the Screenshot app can do! I know that because I googled for it, saw it could do it, and then spent a good 4-5 minutes trying to figure out HOW to do it before I realized the tiny grey scale circle overlaid on a couple of the toolbar icons meant "record".

(Red circles mean record, grey circles don't have much meaning, but hey, need to keep that UI minimal, can't let usability or actual meaning get in the way!)

The Windows Snipping Tool (RIP) is IMHO the best paradigm for doing screenshots.

You are a few versions out of date here -- Mac screenshots now show a preview by default and clicking on the preview opens it for annotation. This is true as of 2018 (Mojave).

> Mac screenshots now show a preview by default

Ah, I have to select "preview". Thanks! That is nice to know.

Now, pardon me, as the highlight tool isn't working, everything is a rectangular selection no matter what I do.

Right click, "text and icons". Thank goodness for that[1], because apparently I have to first click what I thought was a stylized 'A' (or a wishbone), then a separate toolbar appears, that, ironically, doesn't have a way to highlight things. Go figure.

It does appear to be far more powerful than the snipping tool.

I'll still complain about the greyscale record button.

[1] With just icons I probably would have, quite literally, never clicked the markup button and just assumed the preview tool couldn't do any annotations. Holy cow that is a bad icon.

Edit: OIC, the markup button only does something when viewing PDFs, but the button pretends it does something (is clickable, changes state) when viewing image files. That is... distinctly not good UX.

For what it's worth, the much maligned touch bar has good integration with the screenshot functionality, and you can adjust options through that interface while in "screenshot mode". Video recording is also easy there.

I'm also pretty sure recent versions of MacOS have annotation capabilities unless you directly copy to clipboard. Not sure though, don't have a mac anymore.

> The screenshot UI is frustrating, where to save to is under options, you cannot preview your screenshot, you cannot annotate the screenshot (something I do all the time on Windows), and having to choose between saving to file or clipboard is annoying.

I agree with all of this, but for what it's worth: Command-shift-{3,4,5} (and maybe others?) all bring up a rapid screenshot cursor. That action integrates with the little "smart" preview window that recent macOS releases have, so you can just click the little floating window that appears on the bottom right of your screen to see the capture you've just taken.

Command-shift-{3,4,5} (and maybe others?)

Command-Shift-6 takes a screenshot of your touchbar.

Surprisingly useful if you have your touchbar customized to output some kind of diagnostic data or other thing that you're monitoring.

And don’t forget ctrl-cmd-shift-3/4/5 to get it straight to your buffer

That's borderline gang sign.

> (Red circles mean record, grey circles don't have much meaning, but hey, need to keep that UI minimal, can't let usability or actual meaning get in the way!)

Each button in the screenshot toolbar shows a tooltip when you hover over — not even after a couple seconds, but immediately. The one you're talking about is labeled "Record Entire Screen."

> Each button in the screenshot toolbar shows a tooltip when you hover over — not even after a couple seconds, but immediately. The one you're talking about is labeled "Record Entire Screen."

You are right, that is how I figured it out.

By giving up on using visual queues, and hovering over each button individually to see if there were any surprises.

If the circle had literally just been red I would've guessed it immediately.

To be fair Apple's page for this does show the button with the circle over it, I somehow managed to miss the circle despite reading the page twice.

I do have a bias against icons in general, I prefer text labels on all my icons but apparently that is way too 90s. :/

(The dock is largely useless to me, I use Contexts to make MacOS usable, let's me switch apps by typing in the app's name, I have an equivalent program on Windows)

> The Windows Snipping Tool (RIP) is IMHO the best paradigm for doing screenshots.

Obviously it's a little less popular than either the Windows or Mac versions, but I have to say that the KDE screenshot tool (Spectacle) is astonishingly good.

You can launch it (taking a full screen screenshot right away) with a single keypress, set your preferred capture modes (window capture, rectangle), set a delay, take a screenshot on-click, preview the image instantly in the Spectacle window, copy it to your clipboard, annotate the image inside Spectacle (like Snipping Tool), open the image in a different program, upload it to Imgur, send it to your phone, etc etc. All of these are no more than two clicks away in the program.

It's really just astonishingly good.

What I really miss on Windows an Linux is the three-finger drag to slide back and forth between work places, with the rubbery bounce effect (not just an instant switch).

What I miss on Mac is a properly working tap-to-drag, without that delay when you release the dragged element.

>without that delay when you release the dragged element.

Without the delay the system won’t be able to decide if you’ve really finished dragging or just run out of trackpad space but want to continue dragging.

That´s the mac way, right. They decide I have to use my computer a certain way, even if all my other computers work differently, and there´s no way to get the same behavior as on every other Laptop I have (Windows, Linux, Chrome OS). I'd rather be "running out of trackpad space", which is not an issue on those giant Macbook track pads, instead of having to wait for the drag to settle after each drag - or worse, constantly mis-dragging because the behavior, the feel of dragging, is different on MacOS than elsewhere.

Maybe you should try using the 3-finger drag option (Accessibility → Pointer Control → Trackpad Options). I'm using that and it doesn't suffer from this delay issue, because when the number of fingers on the trackpad changes the system knows that the drag gesture was finished.

> double click the image to open it in preview and then drag the file icon of the image into the pages view of the PDF

What I never understood as someone with a mac only to blend in at work, is why in the world is it called Preview when it's actually an editor?

Well, it wasn’t an editor originally... Back in 1989 when Preview.app was introduced in NeXTStep.

I used to love OSX for the same reason, but it's insane how much we've lost in this regard.

Take Photos for instance; I simply can't drag a picture into a browser anymore; it forces me to drag a picture into the desktop, so then I can do something with the file.

Take PDFs in the Notes app; you double click them, they don't open in Preview, but in a weird modal window. Can't drag them to attach in an e-mail for instance; must first drag it to the Downloads folder or somewhere else, to then use the file (and delete it afterwards, so I don't end up with a useless copy).

Photo dragging from Photos to a browser window? Sure you can. I do it all the time.

> Take Photos for instance; I simply can't drag a picture into a browser anymore

They finally fixed this recently, I think it may have even been in Big Sur (or a later version of Catalina).

> The problem with all these Linux/BSD attempts at mimicking the Mac is that due to the nature of the open source components, they are mostly able to mimic the "look" but never the feel.

That's not an open source problem, it's a bazaar vs. cathedral problem. If you built a proprietary system out of 3rd party components, it would have this problem, and an integrated FOSS environment wouldn't (ex. KDE).

One I love is that I can rename a file (or even move it!) while it is open in any macOS app.

The latter will pick up the rename/move and even reflect it in the title bar. You could have unsaved changes to the file in that app, and when you saved it would write to the new name/location.

That would mess up Windows (at least the last time I used Windows, admittedly a long tie ago). Do Linux/BSD-based OSes support this?

Yup, it's a Unix thing.

Looking at the screenshot it took about two seconds for me to notice the white pixels where the alpa channel starts, the vertically uncentered text, and unpleasant choice of font. I'd rather use an OS that had the polish of an SJ era Mac than one that doesn't sweat the details but otherwise resembles the Mac.

Right, and this is because of consistent components and internal APIs in conjunction with enforced deprecation. This was the goal of gnuStep[1] and (more directly) etoile[2], but those projects appear dead these days.

    1 - http://www.gnustep.org/    
    2 - http://etoileos.com/

Étoilé showed some signs of life recently. They've moved to GitHub since Gna! is dead now.

This would also be relatively easy in an office document. PDF is just a terrible format for editing. This specific example however need not detract from your larger point.

Well Windows doesn't attempt to edit PDFs, so what do you expect? If for some reason I was using word it's 2 clicks, so I find that extremely pointless as a test.

> what do you expect?

I think a lot of users expect to be able to do minor manipulations on PDFs.

> To do that on Windows or Linux (I use Mint in my PC) I think I'll have to print the Image as a PDF and then use some other software to "stitch" the two files together.

Actually the process on Linux is similar. On the PDF file, Right-click > Open with LibreOffice (which I believe is installed by default on Mint), then just drag the image onto it. You don't even have to open it, you can just drag the file. On KDE you can even drag it directly from the screenshot software window to the PDF.

Is this really the same? If you open a PDF in LibreOffice, you'll get a version of the document that's effectively converted to an ODT. You're then adding a layer with an image in it, and then re-exporting the result as a PDF. I'd be shocked if this didn't break various parts of the layout or replace fonts, etc.

Really the underlying issue here is that the PDF format is overly complex and not really designed to be edited, so it takes a pretty large number of development hours to build something where editing a PDF in-place works cleanly. Obviously Adobe has software for this, and so does Apple. But it's not an easy ask. Actually, the hard part of this is not the fact that you can drag and drop an image (every Linux app already has this), it's that you can seamlessly edit PDFs in the first place. I would be shocked if there aren't some bugs in Apple's implementation where this breaks unexpectedly.

Bear in mind, it's only 0.4 …

You can mimic the macOS feel in Linux by injecting a 30 ms delay in every action and changing the cursor to a beach ball.

I'm not sure if you got downvoted because humor isn't appreciated on HN or because your joke was bad / not accurate.

> or because your joke was bad / not accurate.

I found it funny, and it does match my experience.

That being said, the only Mac's I've used are several years old by the time I use them.

That's less of macOS itself and more how it fares on Intel hardware. My M1 Pro hasn't really had that.

> That's less of macOS itself and more how it fares on Intel hardware.

It seems fair to expect it to work well on the hardware it was sold on though. I've had the same experience as joked about above on Mac's running the OS that came bundled with the machine.

I completely disagree. I use a Mac for work and basically never leave the terminal and browser. The "finder", which is a terrible name btw, is a completely useless file explorer. For everything a shortcut is needed, and they never make sense. Opening a file? Some key + down. What does Enter do? Renames a file. Okay, deleting a file? I don't know I forgot again. Want to drag and drop? Be real careful that the too-smart-for-its-own-good touchpad doesn't think you are pressing too hard, and don't spend too much time scrolling on top of a folder or it will autommatically expand. But hey at least you have Favorites right? What a wonderful idea, favorites in a file explorer, let's see what they are: first off you have airdrop, which I never enabled and never will. Then you have Recents. What is this about? They are not recent files created via command line, but some random collection of files that Finder thought they knew better about what to call recent, a complete waste of your time. Next you have Applications: What a wonderful idea, to list programs in the file explorer, even though they cannot be interacted in the usual way not have any file navigation to be seen. I guess the only purpose is to be able to drag files into this folder so easily impressed children are amazed by not having seen an installer running. Next you have the desktop favourite, which is important since I don't know any other way of acessing the desktop and it is quite a fitting name for the place only used for screenshots to be created in basically. Finally you have documents and downloads, which are the only real favourites of the bunch. Next you have an ad for the Apple cloud service, and finally you have tags, which I suppose let you aggregate files by color for children that haven't been taught about folders yet. Done with your work? Closing it just hides all windows, to really close the app you have to select Quit from the navigation bar. So at the end of the day I have to select my favorite windows and manually close all others.

If there is any consistency is that I can rely on having a bad experience and anything other than using the touchpad to switch between the same two apps will be better done on another OS.

I was about to call you out on ⌘-Down opening a file but I just tried it and was amazed that it works (most of us do ⌘-o or just double click).

Deleting a file is ⌘-Delete.

Everything in the Finder sidebar is removable (I've removed Recents and Tags, though I find Airdrop and iCloud Drive useful) and you can add custom stuff if you want something else (I always put my home folder at the top of the sidebar, it used to be there by default on earlier OSes).

⌘-Q is useful for closing apps, but I usually just open up the switcher (⌘-Tab) then while keeping ⌘ pressed you can tab over to other apps and just press Q to quit them.

⌘↓ mirrors ⌘↑ for going up a directory, except if you invoke it on a file the logical thing is to open it rather than navigate.

Open is Cmd-o

Expecting Return ("Enter" on Win PC) to open a file is a convention you learned from other OSes. Conversely, imagine my confusion having grown up with Mac OS and being shocked at Windows opening a file I expected to edit the filename of by pressing Enter? :)

Deleting a file? Command... wait for it... Delete

I mean, all of your gripes seem to be about expecting behaviour from other OSes/software and you're not open to learning something new. Different operating systems have different conventions and ways of allowing the user to interact with them.

There are myriad key-commands which can also make your life easier, and they are all pretty easy to remember. I mean, I learned all this stuff when I was literally like 6 years old. As a child I was able to easily remember literally every key command available to the user, in every program I used, including fairly complex DTP software like Quark XPress.

>Return ("Enter" on Win PC) to open a file is a convention you learned from other OSes.

Yes, every other OS on the planet, since the beginning of time. This is just Apple being weird for the sake of being weird.

Guess which came first? It was Finder, and with ⌘O.

Alto had a graphical file manager way before Apple, because of course it did.

Good evening downvoters.

It was called "Neptune", so go ahead and duckduckgo that instead of downvoting facts you don't like.

Hey, I'm not saying the person has to like it, but they're complaining at length about an OS strictly because they are unfamiliar with it.

Also, sorry to disappoint you, but pressing Return has entered name-edit mode for files and folders since literally the very first Macintosh, running System 1.0. I just tried it. I'd love to hear the long list of GUI-based OSes from January 1984 (or earlier) that used Enter to open/execute the selected file/folder, though.

I never said GUI-based. And the list of OSes using Enter to execute commands from <1984 is:

1. All of them.

Even the Alto which Apple... ahem... were "inspired" by.

Yeah, we were talking about a graphical file manager, and selecting a file/folder/executable and pressing Return. Not the same as entering text commands in a CLI. I can see why you'd try to make this argument if you were conflating the two though. /shrug

Not sure I'd take advice on UI/UX behavior from someone who professes to not leave a terminal window... 35 years after better things came along. I know I live back when terminals were all we had. Boy were we happy when that wasn't true anymore.

No matter how much you like typing everything in a terminal, it is the least efficient environment for file system navigation. It lists file systems in 1-D where you...have....to...type...out...paths and cache the organization in your own memory. The poor UX of the terminal leads to lot of bad habits, like shortening names to acronyms, reducing hierarchy for typing convenience, and dumping files an unorganized mess (looking at you usr/local/bin). GUI file navigation is 2-D or even 3-D organizations of files that together with spotlight indexing I know I outrun terminal navigators by 10X in a real-world file system.

> The "finder", which is a terrible name btw, is a completely useless file explorer.

…it finds files. Is "Explorer" somehow a better name? No comment on it being useless, as that's not something I can respond to, obviously.

> For everything a shortcut is needed, and they never make sense.

Uh, no? You can literally do everything with your mouse, and they all make sense as the other commenters have mentioned.

> don't spend too much time scrolling on top of a folder or it will autommatically expand

You can configure that, it's call the "spring loading delay" in System Preferences.

> first off you have airdrop, which I never enabled and never will

That sounds like a "you" problem.

> They are not recent files created via command line, but some random collection of files that Finder thought they knew better about what to call recent, a complete waste of your time.

They're recent as in what you opened recently.

> Next you have Applications: What a wonderful idea, to list programs in the file explorer, even though they cannot be interacted in the usual way not have any file navigation to be seen.

You can copy them, move them around, delete them…I fail to see your point.

> I suppose let you aggregate files by color for children that haven't been taught about folders yet.

As opposed to the mature adult writing this.

You've spent half of the post ranting about a sidebar you're free to rearrange, add new folders to it and remove the ones you don't like!

Honestly, not understanding a difference between file tagging and file hierarchy is something I wouldn't expect here on HN.

Also, you can, wait for it, create your own tags, rearrange them and remove the ones you don't like!

Reply on news.ycombinator.com