Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need to document macOS

eclecticlight.co

Post reply on HN
Print view View original

131–140 of 266 posts

Re: We need to document macOS

#131

Post by captainmuon »

SwellJoe wrote: post #110
captainmuon wrote: post #86

Earlier quoted context omitted.

It's not Apple's work to do. It's not in their interest to document everything. What applies to internal APIs applies to lesser extent to the detailed workings of the OS, like the init system, themeing, etc.. If it is documented, people will depend on it, or write low-level tweaking tools that Apple doesn't want to exist. What is good for customers and developers might not be good for Apple, and vice versa. (A separa…

If the experience of developing for the OS is terrible because the documentation is terrible, well...an operating system without a thriving application ecosystem is an operating system that is not long for this world. No matter how good the OS may be. Computing history is littered with the corpses of better operating systems (Amiga and BeOS and every UNIX other than Linux come to mind) that didn't have the app ecosys…

I'm just being charitable and assuming Apple knows what it is doing - e.g. assuming "malice" instead of stupidity.

For example, macOS is themeable under the hood. Nearly all Cocoa controls are defined as vector graphics in an "art file", rather than hardcoded in the library. This was probably not done with themability in mind, but is just a side effect of good engineering. I bet there was a meeting where the engineers said "we have this great feature where we can change the theme of all Cocoa apps", and it was decided to not expose that feature for reasons like "brand recognition" and having all macs look alike for support reasons. I'm pretty confident that happened because Microsoft did the same and locked down themes with Windows XP (and somebody stated their reasoning), and also the GNOME project removed theming from the main UI and crammed it into a scary "tweak" tool (one dev said basically that theming is not a desired feature for them).

Similar logic applies to other things, like the kernel interface.

I fully understand why they come to such decisions - but I as a user and developer (and interested in "hacky" things) would love these things to be documented.

I don't think the status it is hurting their bottom-line, or the quality of mac apps (yet). Cocoa stuff seems to be documented decently enough. But I agree, they have to be careful if they don't want to fall behind.

Re: We need to document macOS

#132

Post by sd8dgf8ds8g8dsg »

stuntkite wrote: post #102
givinguflac wrote: post #97

Earlier quoted context omitted.

I agree. Years ago Finder left much to be desired, but with all the updates of the last few revisions I'm not left wanting for anything. People complaining about searching likely haven't tried smart searches, it's awesome. Can anyone specifically call out what their issues are with Finder besides "it sucks"? I really feel that I'm missing something here.

I have not used smart searches, and now I'm reading about them and it does look pretty cool. But that search bar should give me something sort of close to what I'm looking for in a couple strokes and it really doesn't. I can specifically call out what my issues are with Finder. - Where is my fucking folder tree. There was no reason to take it away other than "thinking different" just like the backspace key. Super spe…

> - It appears to be designed to keep you away from the system HD. More and more so with every release. I want to look at my filesystem, it it's entirety, easily and without using "go".

One "pro tip" is use "Cmd + Up arrow" to navigate one level above current folder.

Also, Finder creates ".DS_Store" files in each folder, which remembers current folder display. If you want to enforce say "List files" view everywhere, you will also need to nuke these from your system.

There is Path Finder, which is a good software (Shareware) that has a more traditional take on file explorer software, which might be good to check out if you are coming from Windows or Linux.

Myself, I'm just giving Finder a second chance, after having used Path Finder for a couple of years. It is well worth learning some of the key combos for better use.

Here is some more:

In finder, or in a "Open file" dialog, you can type "Shift + Cmd + G" to get a "Go to folder" dialog.

In finder, or in the "Open file" dialog, you can type "Shift + Cmd + ." to toggle "Show hidden files" (.dot files).

Re: We need to document macOS

#133

Post by ZenoArrow »

unkown-unknowns wrote: post #2

> Yet Apple’s documentation for users and those supporting users has all but dried up You and me we both RTFM, but the population at large? Not so much. When computers were in their early days more of the people that used them were willing and even interested to learn a lot about what was going on. Now the computer is a tool used by most people to do specific tasks. Just like I don't care to learn how to fix my car t…

I'd say it ties up with Apple's focus on being a consumer electronics manufacturer. Apple and Sony have more in common than Apple and Dell.

Re: We need to document macOS

#134

Post by hungerstrike »

delinka wrote: post #89
anonymfus wrote: post #84

Earlier quoted context omitted.

> The real kicker is that STILL many errors produce a window where I can't even fucking copy the output. Why that is still a feature, I have no idea. BTW a standard way to do it is to just press Ctrl+C in such window without any text selection or context menu. Because such messages could be shown when system has no resources to create context menu or text selection, and that was very important in 16-bit days.

Let me klingon to the thread with this: It's 2017 and I still can't use the keyboard to copy and paste from and to a Windows command line window...

Yes you can. Try it out.

Windows has better keyboard accessibility than any other desktop OS.

Re: We need to document macOS

#135

Post by sd8dgf8ds8g8dsg »

pwinnski wrote: post #121
stuntkite wrote: post #102

Earlier quoted context omitted.

I have not used smart searches, and now I'm reading about them and it does look pretty cool. But that search bar should give me something sort of close to what I'm looking for in a couple strokes and it really doesn't. I can specifically call out what my issues are with Finder. - Where is my fucking folder tree. There was no reason to take it away other than "thinking different" just like the backspace key. Super spe…

Unfortunately, your points aren't numbered, but I'm confused by a couple of them. - Finder has had tabs for a few releases, and I can't recall the last time I had multiple Finder windows open at the same time. I use tabs for everything. - By "sliding cell" do you mean the columns view? I use the list view roughly 100% of the time, so I'm no help there. - On my system, quicklook opens a preview to the left of the find…

For showing "system hidden files", most popular is the ~/Library, run this command in terminal

    defaults write com.apple.Finder AppleShowAllFiles YES
For toggle display of hidden & dot files, type "Shift + Cmd + ."

Re: We need to document macOS

#136

Post by ThrowawayR2 »

sillysaurus3 wrote: post #107
stuntkite wrote: post #79

Earlier quoted context omitted.

Can you elaborate on what technology choices I'm missing? Lets just say specifically the Finder issue. Is the solution to use Linux as my desktop environment? I mean this honestly, I'm not trying to be flip. Can you give me some examples of the solutions that other people have moved to years ago that you are referencing? I am very open to the fact that I could have just totally missed the train to a better creative t…

I use `find . | egrep -i foo` to find foo on OS X. ~/Downloads$ find . | egrep -i lisp ./ANSI_Common_Lisp_-_Paul_Graham.pdf ./lisp_in_small_pieces.pdf ./onlisp.pdf It works well on an SSD. I also wrote a script called `narrow` which lets you pass in several terms to narrow the results by. ~/Downloads$ find . | narrow self pdf ./An Efficient Implementation of SELF, a Dynamically-Typed Object-Oriented Language Based on…

The original poster already said "I normally default to locate or find now...", so presumably he's well aware of find.

Re: We need to document macOS

#137

Post by throwanem »

yoz-y wrote: post #46
throwanem wrote: post #37

Earlier quoted context omitted.

You're totally being factious in favor of free software. Not facetious, though, I agree. To your actual point, what hampers free software more than anything imo is a lack of focus on usability. People buy Apple because, less now than a few yeara ago but still the vast majority of the time, it Just Works. People buy Creative Cloud for much the same reason, and Office 365, and whatever other proprietary products you ca…

ElementaryOS seems to be going in the right direction. But I suppose the main "thing that works" is to have a team of people that actually enjoy making software usable by the masses rather than solving X for their own needs.

That's a rare sort of intrinsic motivation, though, and tends not to last long in the face of frequent contact with users who, having their own situations to deal with, reasonably tend more often to complain about software that fails to make their lives easier than compliment that which does. That's where extrinsic motivation needs to come into play, but it's not much on offer in the context we're considering.

Re: We need to document macOS

#138

Post by wbl »

fnord123 wrote: post #129
notalaser wrote: post #109

Earlier quoted context omitted.

> But, I'm kinda baffled why anyone would volunteer to provide free labor to one of the largest and most profitable companies in the world. YES! MacOS users don't need to document macOS as a volunteer project, they need to demand Apple to give them their money's worth.

And yet Apple does not contribute to homebrew at all. The one project that makes osx usable for developers.

They did contribute to Macports which does the same.

Re: We need to document macOS

#139

Post by sd8dgf8ds8g8dsg »

jcelerier wrote: post #108
stuntkite wrote: post #79

Earlier quoted context omitted.

Can you elaborate on what technology choices I'm missing? Lets just say specifically the Finder issue. Is the solution to use Linux as my desktop environment? I mean this honestly, I'm not trying to be flip. Can you give me some examples of the solutions that other people have moved to years ago that you are referencing? I am very open to the fact that I could have just totally missed the train to a better creative t…

> Lets just say specifically the Finder issue. Is the solution to use Linux as my desktop environment? Yes, especially with KDE's Dolphin file manager which is more or less the pinnacle of GUI file browser. See https://www.youtube.com/watch?v=jkWuVCKpiXs it becomes especially good when you start taping in its scripting capabilities and the wealth of scripts available: https://store.kde.org/browse/cat/102/ .

Please be cautious about recommending KDE's Dolphin. According to Hanno Böck in https://media.ccc.de/v/SHA2017-148-improving_security_with_f..., KDE are refusing to sandbox the thumbnail/preview code, which has proven to be riddled with easy-to-find bugs (using software fuzzing)

Re: We need to document macOS

#140

Post by nebabyte »

pjc50 wrote: post #10
static_noise wrote: post #7

When it's documented it cannot be changed as easily, so it's often better to not document everything in detail.

Then your users find that their own memory of where to find things and how to perform tasks is unreliable. Has the system changed or they forgotten it? You're effectively "gaslighting" your users if you rely on this.

Apple gives users APIs at the level they think users should be operating, not system internals.

Are we seriously having this discussion, HN? Did people just wake up today to what their reality has been for years? https://www.youtube.com/watch?v=ilcRS5eUpwk

Post reply on HN