[Update Discussion] TotalFinder 1.15.1 for Apple Silicon and Intel — macOS 13, 12, 11, and 10.15

@akemin_dayo,

Thank you for your detailed response. It’s always nice to get a software engineer’s thoughts on Apple’s software and hardware decisions. It helps me to view Apple from a different perspective.

As for my accessibility concerns, I’ll briefly clarify what I meant. I agree that Apple has done a lot for accessibility and has a great many accessibility features.

My complaint is primarily about the default visibility of the UI of macOS. Especially with Big Sur and Monterey, Apple seems to be designing the UI to appeal best to young people with superb vision. All the transparency features that are on by default in Monterey are one example of something that causes problems for middle-aged and elderly people. And in Monterey, it’s become more difficult to distinguish between a foreground window and a background window. There’s a lack of depth and definition.

Fortunately, there are ways to mitigate this via System Preferences, but they’re buried. My middle-aged and elderly family members have no idea where to find these settings and so inevitably they call me.

There are other poor UI features I could mention (e.g., the stupid hidden Show/Hide button in Mail’s sidebar that only appears when you mouse over it) but this is off-topic and I really should write a detailed complaint/plea/argument for Apple Feedback in the hope they would make some changes.

1 Like

@strafer

Huh. I must admit, I’ve never thought of Apple’s new, post-macOS Big Sur UI in this way before, speaking as one of said “young people with superb vision”.

Anecdotally, none of my middle-aged (or older) family members have ever complained to me about the UI on either macOS or iOS as being difficult to “read” (for the lack of a better word) before.

They’ve generally only asked me regarding increasing the font size (Dynamic Type), and in the case of iPhones, enabling the larger UI scaling as well (where iOS will use the internal render resolution intended for a 4-inch display, but scaled up on the larger 4.7-inch display instead).

(… That being said, I also haven’t spoken to any of said family members in a long while now, considering their… hostile stance on the fact that I happen to like women.)

Curious — back when Aero was being used in Windows 7 and Windows Vista, did these people have the same issues with that UI design as well? Or were they always Mac users?

Aero also had a lot of transparency in its design, even moreso than modern macOS which goes for more of a translucent, “frosted glass” look.

Hmn, yeah. I feel like Apple should probably consider asking users if they would like to enable the high-visibility / high-contrast UI as part of the post-upgrade or new-install (OOBE) onboarding process — it would definitely increase discoverability of that feature even existing to begin with.

… It might also just already be there, but hidden away in the “Would you like to enable any accessibility features?” prompt (the one with the “Vision”, “Motor”, “Cognitive”, etc. buttons), which kinda leads into the next thing…

Yeahhhhh… UI discoverability in newer versions of macOS and iOS definitely need to be improved, I feel. There’s lots of features just hidden away in often strange ways, causing many users to not know that they even exist to begin with.

Even things like the Document Proxy Icon (the little icon normally at the top of the titlebar) require a rather undiscoverable mouse-over to reveal now, at least in Finder.

※ EDIT: Apparently Apple added an option to always show the Document Proxy Icon in macOS 12. … Though I wonder why they choose to put this option in the Accessibility preferences, instead of in the Finder preferences.

I think I’ve had at least six or seven different people contact me in a panic, saying that they’ve “lost their email”. I know immediately what the issue is: they’ve accidentally clicked on the “hide” button in the Mail sidebar and hidden their mail folders.

The fact that they don’t know they did this or how, nor how they can restore their email by “unhiding” it, is mostly due to bad UI design or poor UI discoverability, as you said.

And yes, Apple choosing to hide the proxy icon is another baffling decision. I guess I just need to calmly ride the waves of their design whims and experiments and screw-ups.

1 Like

So, I just discovered that if you type or paste an emoji into the name field of a folder (e.g., rename a folder with an emoji) and drag the folder into the Finder sidebar, the emoji will be displayed next to the folder icon.

folder_emoji

Why would Apple remove custom folder icon support in the Finder sidebar but display emojis in folder names in the sidebar?

1 Like

@strafer Apple didn’t really specifically go out of their way to add this functionality into Finder, it’s just a natural result of the fact that Finder (and most macOS/iOS/etc. apps) use their CoreText framework to handle font rendering, and CoreText on all appleOSes just also happens to be able to handle emoji rendering.

For instance, emoji render in Terminal, too.

(※ Technical note: Emoji functionality on appleOSes is actually implemented via a coloured bitmap font — “Apple Color Emoji”. iOS jailbreakers even developed a method to backport new emoji into older iOS versions!)

Not working in M1 Mac 11.6

What should I do?

@674423114 Can you run sudo bputil -d in Terminal and tell me what everything underneath “Security Mode” says?

It should look something like this.

Security Mode:               Permissive (smb0 && smb1): 1
3rd Party Kexts Status:      Enabled    (smb2): 1
User-allowed MDM Control:    Disabled   (smb3): absent
DEP-allowed MDM Control:     Disabled   (smb4): absent
SIP Status:                  Customized (sip0): 7f
Signed System Volume Status: Enabled    (sip1): absent
Kernel CTRR Status:          Disabled   (sip2): 1
Boot Args Filtering Status:  Disabled   (sip3): 1

(※ Do not post anything above “Security Mode”, those hashes are unique per-install.)


※ EDIT (by Karen): Re-cropped the image to remove install-unique hashes and a partial ECID. Also disabled public edit diffs for this post.

@674423114 Hmn… okay, so your SIP / BootPolicy configuration is valid.

Try running this in Terminal.

sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true

And then reboot your Mac just so we can make sure we have a clean state.

If it still continues to fail, please run this in Terminal:

/Applications/TotalFinder.app/Contents/Resources/diagnose-totalfinder.sh

And then send me the resulting totalfinder-diagnostics.tar.gz file on your Desktop to me at karen@akemi.ai.

(※ You can just say “no” when it asks you for permission to get your BootPolicy, since I already have the info I need above.)

Do you mean sudo defaults write rather than read?

1 Like

@Peter_Hollo I indeed did, oops o)-<

Thanks for catching the mistake!

1 Like

:sob:

It still does not work, and I send the diagnosis to your email. Hope to help you

1 Like

@674423114

Hmn, this is… a very strange issue you’re running into.

I can’t reproduce this, nor have I ever seen this happen — at least, not on 11.6.5.

I’ll try installing 11.6 later when I have time, and see if I can get this to happen.

A simplified explanation of your issue would be that for some reason, the AppleScript runtime on your system somehow doesn’t seem to be aware that TotalFinder is even installed.

Or for a slightly more technical explanation, our custom AppleScript event handlers used by the TotalFinderInjector component that lives in /Library/ScriptingAdditions/TotalFinder.osax aren’t being detected or registered by your system’s AppleScript runtime.

Basically, TotalFinder.app fires an AppleEvent called BATFinit. Upon receiving this event, AppleScript performs a lookup against all AppleScript event handlers, both built-in and third-party (“ScriptingAdditions”), to see if anything is capable of handling that event.

On a working system, AppleScript would find that TotalFinder.osax is capable of handling BATFinit, and then it will pass the event to it, which then results TotalFinder being activated.

(※ The specific error you are experiencing is errAEEventNotHandled (-1708), or “The script doesn’t understand the message. The event was not handled”, as per Apple documentation.)


Try this:

  1. Uninstall TotalFinder, using the TotalFinder Uninstaller.app from the downloaded DMG.
  2. Reboot your Mac for a clean state.
  3. Reinstall TotalFinder from the PKG.

You won’t have to re-do any of the Apple Silicon steps or anything.

If the issue still persists… I will try and get macOS 11.6 installed on a test machine and see if there’s some strange bug specific to just that version.

※ EDIT: Also, if you haven’t already, please try the instructions on this page.

1 Like

Thank you very much for your technical support. I will reinstall the Mac Book system to try to use TF

Interesting.

Since folders can now be named with emojis, how do other file systems (e.g., exFAT, ext4) or cloud backup systems like Backblaze “read” emojis as filenames when they’re copied to them from APFS?

If I have a folder, ~/Desktop/ :thinking:, and I copy it to my NAS and then I connect to the NAS from a Windows or Linux machine, how is that folder displayed? Do Linux and Windows also support emoji in file/folder names?

Also, if I drag a folder with an emoji name into the Terminal, the path ends with the emoji image. But I assume the system must be translating it into a text name or something.

It would be fun to use emojis to name folders and files, but I would be afraid of data loss if I ever had to restore these emoji-named folders and files from a backup, especially from a NAS or cloud backup.

1 Like

@strafer This may seem very counterintuitive, but emoji are actually text.

Well, that’s an oversimplification. What I mean is that they’re Unicode codepoints. Which is basically text.

Basically, what this means is that emoji are actually encoded and handled in the same way that say, a Japanese character would be.

For instance:

あいうえお (a i u e o, the 5 vowels written in Japanese hiragana script)

  • In UTF-8 representation, the above would be \xe3\x81\x82\xe3\x81\x84\xe3\x81\x86\xe3\x81\x88\xe3\x81\x8a.
  • In UTF-16 representation, the above would be \u3042\u3044\u3046\u3048\u304a.

aiueo (same thing as above, but now with Latin characters)

  • In UTF-8 representation, the above would be \x61\x69\x75\x65\x6f.
  • In UTF-16 representation, the above would be \u0061\u0069\u0075\u0065\u006f.

🍍🌺🎋🍕🌭

  • In UTF-8 representation, the above would be \xf0\x9f\x8d\x8d\xf0\x9f\x8c\xba\xf0\x9f\x8e\x8b\xf0\x9f\x8d\x95\xf0\x9f\x8c\xad.
  • In UTF-16 representation, the above would be \ud83c\udf4d\ud83c\udf3a\ud83c\udf8b\ud83c\udf55\ud83c\udf2d.

Basically every modern (or modern-ish) filesystem in use today — APFS, HFSJ+, ext4/ext3/ext2, ZFS, NTFS, exFAT, and even FAT32/FAT16/FAT12 (thanks to Microsoft’s backwards-compatible “Long Filename” feature) supports storing and retrieving unicode characters as filenames or directory names.

Generally speaking, the only issues you’d potentially run into are if you tried to view these filenames using an operating system that doesn’t correctly supports Unicode, such as early versions of Windows XP.

But even then, you’d still be able to access the files. The folder name would simply be displayed incorrectly, as mojibake. (tl;dr: A Japanese word that ended up in the English lexicon, used to describe what happens when a non-Unicode aware OS attempts to render Unicode text with the wrong encoding.)

When dealing with actual data access or I/O in filesystems, computers really only care about the raw UTF-8/UTF-16 representations I showed above. Actually displaying said Unicode data to the end user is a completely separate thing. As a result, data loss due to Unicode filenames doesn’t happen. (If it did, a large portion of the world would be screwed…)

As for how your emoji will render/display on each OS… that’s just up to each individual OS’s emoji support. If your OS doesn’t support rendering a specific emoji, you may see a � replace it instead.

Hopefully this makes sense to you.

tl;dr: Emoji are text. Naming something with emoji is just like naming it in Japanese or another foreign language script. As for how it’ll be displayed, it’ll probably be correct as long as you’re using a reasonably modern OS. Really just depends on the emoji support in general on said OS. Data loss shouldn’t really happen — all modern filesystems support Unicode. Also, the rest of the non-English-speaking world use computers too ;​P


※ Fun fact: There are actually literal Egyptian hieroglyphs in Unicode, as well.

1 Like

Yes, thank you, that makes sense. Very helpful.

1 Like

I’m running TotalFinder under Monterey Beta 21F5071b (12.4 beta 4) on a M1 MacBook Pro Max and it’s running very well. It’s great to have it back and operating like normal. I tried PathFinder and a bunch of other programs but none did everything (or as well) as TotalFinder. Thanks for your great work.

1 Like

Hello, first off many thanks for the update. I wasn’t looking forward to a future of Apple Silicon minus TF. I just wanted to add my two cents as to what I’m observing with native tabs on two Mac platforms:

  • 2020 iMac (Intel, Big Sur 11.6.5) TF has native tabs on both sides in dual mode, but the native tabs on the right won’t go the full width of the frame. This issue has been present at least since Big Sur’s release.

  • 2021 Mac Mini (M1, Monterey 12.3.1) TF installs and runs fine, but native tabs in dual mode don’t work at all on the right side. Trying to get them to work makes both sides inoperable.

Again, my eternal gratitude for the update!!

2 Likes

Thanks for much for this! I’ve completely avoided upgrading past 10.15 or buying new Macs, and this was one of the biggest reasons (the IU and lack of control in 11+ is awful). I’ll be testing this on my family M1 Mac mini. Maybe this will finally convince me to upgrade my 2010 Mac Pro to an Apple Silicon Mac.

1 Like