I’m with you on the “I don’t think that it’s top priority”. I’m asking to review the tab design only if it’s easy to implement (and seems like it’s not) and actually people like the idea (and that point remains unclear). I’ll remain being a TotalFinder user whatever happens.
I have tried to get their new code and merge it with my old one a few months ago. The problem is that they newly use bitmap-based rendering (originally they used Mac System drawing APIs to render those tabs). The reason behind this was to support user-skinning of Chrome windows and tabs. But I hit the wall because I would have to bring whole skinning subsystem and related dependencies into TotalFinder.
Actually I was almost there, you can see from TotalFinder resources that I have all their bitmap resources in TotalFinder already[1]. TotalFinder has partial support but it was never finished. Beta users complained about the new rendering and I got distracted with more serious issues.
I’m considering taking omnibar implementation from Chrome to support alfred-style jumping to arbitrary paths (like you do with URLs in chrome after hitting CMD+L). This will be a good opportunity to revisit this again and modernize my code.
In the meantime you may try to enable this tweak:
defaults write com.apple.finder TotalFinderBitmapTabs -bool true
To disable it:
defaults delete com.apple.finder TotalFinderBitmapTabs
This will enable bitmap rendering code-path. But I’m not sure if it is not broken.
[1] https://github.com/binaryage/totalfinder-i18n/tree/master/plugin
That’s really helpful! I’m gonna try your suggestion and report back if I get into something weird.
Thanks for your thorough reply, Darwin.