MacOS - Christmas Sneer

[tperry2x]

Just found more instances of Apple interference (or rather, changes that they decided to inflict on users).

In the finder, I was going to the /Applications folder.
You'd think this was straightforward wouldn't you?
You'd think the path for "TextEdit.app" would be "/Applications/TextEdit.app" wouldn't you?

displays-incorrectly.png (16.37 KiB) Viewed 796 times

You'd be wrong.
If you right-click and "show package contents", drag the "contents" folder from inside the "TextEdit.app" bundle into a terminal window. I'll reveal it's real path as:

where-it-actually-is.png (34 KiB) Viewed 796 times

You can also copy the path to this folder (more on this in a sec) to confirm the real path of it on disk. You hold down the alt key while the edit menu is open and the folder is selected in the finder:

copy-pathname.png (253.86 KiB) Viewed 796 times

That also reveals the real path to this is no longer "/Applications/TextEdit.app", but "/System/Applications/TextEdit.app".
When was this changed? It didn't used to be like this. You could have a user applications folder at ~/Applications but there's no need for the "System" prefix at all. This means I have to check for two locations in case a stack is being run on MacOS pre-this-"system" prefix.

Also, when was "grab.app" removed?
I know I can do command-shift-5 to do a timed screenshot now, but it's cumbersome and the interface for defining the screenshot is clunky.

I tried to export the rect of the screen as a screenshot, but the IDE fails to capture open menus in a screenshot when it's not the foreground app:

nope.png (55.58 KiB) Viewed 796 times

I know this used to work (pre-catalina) - so that's something else that seems broken on MacOS.

[richmond62]

Baking bread, running washing machine, vacuuming house, having large cup of coffee . . . and only then . . .

Oh, and how the @#£%^& does moving TextEdit from wherever it WAS to wherever it IS affect either the end-user, or more specifically OXT users?

The FORM and the FUNCTIONALITY of TextEdit have not changed at all.

Let's face an unfortunate truth:

The whole WIMP GUI thing is either a metaphorical extension of my grandfather's roll-top desk, or it a trick so that:

1. End-users don't have to fiddle around with hexadecimal machine code to get a computer to do anything: I tried that in 1985 and got almost nowhere: at the time, if you can believe it, I thanked God for FORTRAN and PASCAL.

And the congery of magnetised iron-oxide molecules that look to Thee and Me like TextEdit are really nothing more that a congery of 'wot ever' on a hard drive, or something even more freaky on an SSD.

Personally I don't give a damn where those molecules are (and I doubt very much that many other people do: and the average Ned who uses his PC to play "Porn-Catcher III" doesn't even kniw what iron-oxide is {probably thinks its an energy drink}): all I care about is that 'TextEdit' sits in my 'Dock' at the bottom of my screen for when I need to use it.

AND, before bashing Apple about TextEdit (there are far bigger things to bash Apple about), consider how you might locate a text editor in a Linux distro.

For all its manifest sins, Apple does, at least bung most of an App's (there's another 'metaphor') in one place.

[tperry2x]

Oh, and how the @#£%^& does moving TextEdit from wherever it WAS to wherever it IS affect either the end-user, or more specifically OXT users?

Because if you are checking to see if an app exists and is installed, you have to guess if it's going to be in /Applications or /System/Applications now.

The FORM and the FUNCTIONALITY of TextEdit have not changed at all.

I'm not talking about the functionality, just locating the damn thing via a command line.

Personally I don't give a damn where those molecules are...

Maybe you don't, but anyone coding / scripting anything definitely does.

mav.png (53.24 KiB) Viewed 786 times

AND, before bashing Apple about TextEdit (there are far bigger things to bash Apple about), consider how you might locate a text editor in a Linux distro.

I'm not bashing apple about textedit, rather changes to their system. And incidentally, it's easy to find installed apps in linux.

For all its manifest sins, Apple does, at least bung most of an App's (there's another 'metaphor') in one place.

No it doesn't. That's the point of this post.

[richmond62]

Because if you are checking to see if an app exists and is installed, you have to guess if it's going to be in /Applications or /System/Applications now.

Agreed: that could be a pain in the bum. I suppose you'd have to have code to check in both places.

Over 'here' (MacOS 12.7) it seems that all the apps that the Mac system automatically installs (and for the life of me I cannot work out how to remove some of them) are REALLY in the /System/Applications folder, likewise /System/Applications/Utilities . . .
-

Screenshot 2024-12-28 at 12.23.21.png (218.4 KiB) Viewed 781 times

-
It would be interesting to work out HOW Apple gets those Applications to appear in 2 places at once . . .

. . . obviously some sort of symbolic link that end-users cannot see as such.

[richmond62]

No it doesn't. That's the point of this post.

Sorry; that was me being all fingers and toes with the Android phone:

For all its manifest sins, Apple does, at least bung most of an App's (there's another 'metaphor') in one place.

should have read:

For all its manifest sins, Apple does, at least bung most of an App's constituent files (there's another 'metaphor') in one place.

Meaning that what looks like a monolithic file is a disguised directory containing all an app's dependencies.

[richmond62]

changes to their system

Well, my friend has a LADA car he bought in 1986 (after a 20 year waiting list - the joys of communism) that still runs smoothly, but has no airbags, no climate control, no automatic this-and-that.

Our 14 year old Toyota Auris is, relatively speaking, and "all-singing-all-dancing" concern: and, as a consequence changing the clutch was not a simple matter of popping down the local "Avtimorga" (breaker's yard) and picking up a 'new-fer-you' clutch for 20 quid, and paying Georgi down the road another 20 quid to install it. It involved waiting a week while the fancy-pants repair shop ordered a new one, and 500 quid for component & labour.

But, churning up the motorway the other day at 140 km per hour (speed limit in Bulgaria), I was rather happy I was not driving a non-power-steering, non-heated LADA (it being -5 C outside with a strong wind) at 80 kph: mainly as coming up behind a chain of 7 Turkish lorries, a Lada would just not have the acceleration power to overtake them: and having played "sandwiches" between lorries far too many times . . .

My friend is in the processing of customising his LADA in all sorts of jazzy ways: something you just cannot do with a Toyota.

Now, like it or not, within the next 4-5 years I will have to buy a new car, which will probably be another Toyota; which, inevitably will cost a LOT of money: so, I will want a lot of 'bang for my bucks'.

Apple are in the business of selling their 'monolithic' system to people who want 'bang for their bucks' rather than something they can have for next to nothing (Linux) to run on any old bit of hardware and transmogrify into very nearly whatever they want.

So: my recommendation is NOT to check for the presence of a text editor on a Mac system, but to find something that can be bundled inwith the OXT package.

[tperry2x]

changes to their system

Well, my friend has a LADA car he bought in 1986 (after a 20 year waiting list - the joys of communism) that still runs smoothly, but has no airbags, no climate control, no automatic this-and-that.
...
My friend is in the processing of customising his LADA in all sorts of jazzy ways: something you just cannot do with a Toyota.

That's kind of how I feel about our inherited engine. A LADA analogy is quite a good one.
Ultimately, we can try and dress it up as much as we like, but it's always going to be a LADA. My hope is, gradually we'll replace so much of it that it stops looking like a LADA, even if the underpinnings show that's what it started life as.

So: my recommendation is NOT to check for the presence of a text editor on a Mac system, but to find something that can be bundled inwith the OXT package.

Well, that's what you already have - with the built in script editor. What I'm looking for is the ability for a user to easily select from a preset list of known compatible editors (if they happen to have them installed on their system).
If you mean, something we can include with the OXT Lite install (a bit like the MONO editor used to come with Unity), then that could be an unwelcome addition and an annoyance - not to mention the licensing and codesigning headaches of that app too. No, I think I'll stick to a user-selectable list as that will be far easier.

I'll leave it up to the end-user to deal with their own potential code-signing issues with their text editor of choice, rather than creating another set of issues with an OS that is increasingly being locked down.

A bit like your Toyota analogy - MacOS is fast becoming the OS you have to take back to the dealership to get something fixed. It might be able to do 100 mph+, but not much good if it spends the majority of it's time up on ramps.

[OpenXTalkPaul]

I just noticed this thread here, I missed during the holidays.
Well this IS a new development but I can't say that it is a surprised as Apple started moving various utility apps into various subdirectories of the (special privileged) /System/ directory some time ago.

However this should not affect our .app bundles (or paths to stacks inside of them) in anyway. I'm sure this can only apply to software that Apple ships (apps included with the OS) because only Apple is meant to be able to modify anything in the /System/ directory, as if it is like firmware. You can also have /User/~me/Applications/ but I don't think many people bother doing that (I've used that). I assume what is now showing as /Applications/Text Edit.app is a Symbolic Link because that would be the easiest way to do that (I've used Sym links technique to store massive libraries of sound samples on addition storage devices the same way )

And you know what they'll say, they "did it for your safety". Here's a senario: Apple code signature is on those apps, so... THEORETICALLY (nudge:nudge, wink:wink) one could make a copy of such an Apple signed thing like 'Text Edit.app' and replace it's internal binary executable with a different binary. possibly tricking the system into thinking that it's a nice and safe Apple signed Application, which could really screw up some security measures if SOMEONE were to do that with OXT: Apocalypse version Each major version Apple has tightened their grip on what most users can and cannot do with the products that they've purchased from Apple, so that the sort of shenanigans I mentioned here can no longer take place, ostensibly protecting customers from ourselves.

Calculator is the same way (on macOS 15.2) but Safari.app is not, probably because it frequently needs to be updated as soon as possible to patch security flaws in between macOS updates.

EDIT: I was wrong, I just looked it up and Apple can update the apps in System/Applications without user interaction, so I'm not sure why Safari isn't in there too.

If you try to drag a copy of the Text Editor.app bundle out of /Applications/ you'll get a 810 byte file that reports itself to be an alias (but could be making an alias to a sym link)

Apps installed by the end user into what appears as /Applications, in newer versions of macOS, they are actually stored in a 'Data' partition IIRC. It's all part of a long term shift to a much smaller 'Sandbox' for users to play in'.

I think one should always check for the real path to an 'app' bundle, for one thing you can store and launch Mac .apps from your Apple account's iCloud, which would actually be launching them from an iCloud cache folder in /User/~username/Library/Application Support/ or somewhere like that. I forget exactly where because I wrote a script to open that directory in the Finder

[OpenXTalkPaul]

I cannot work out how to remove some of them) are REALLY in the /System/Applications folder, likewise /System/Applications/Utilities . . .

You'd have to disable System Integrity Protection (SIP) from a terminal command and reboot with that off in order to remove macOS installed software, Apple does not want you doing that. So you must disable SIP as described or you'll just have to live with /System/Applications/Chess.app taking up space on your drive even if you'd rather have had Checkers.app (I believe that game is called 'Draughts' on your side of the Atlantic). I know it's a pain, there's been a few times when I've needed to free up a few hundred megabytes on main drive, where previously you could run an app called Monolingual and to remove more than a gig of large Asian Fonts and other languages files that I'll never use. I have an extremely stepped down version of Mac OS X 10.4.11 (Tiger) that is like that, just a couple of gigs of space for the core OS, English only!