<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8"> </head> <body> <div style="font-family:sans-serif"><div style="white-space:normal"> <p dir="auto">On 8 Sep 2019, at 9:00, Marc Wilson wrote:</p> <blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"> <p dir="auto">Apple’s broken idea of what tabs are is completely unusable. Poorly implemented and hard to use, hard to distinguish between tabs, etc.</p> </blockquote> <p dir="auto">Well, it seems to me at least that:</p> <ul> <li>TextMate's implementation uses the same colours, fonts and outlines.</li> <li>TextMate's tabs are a bit thinner, which saves a bit of screen space but at the expense of making it easier to "miss" when dragging and dropping tabs to reorder.</li> <li>Tab height aside, TextMate and Apple tabs appear to be visually almost indistinguishable.</li> <li>TextMate and Apple tabs both support drag-to-reorder.</li> <li>Apple's dragging seems as responsive as TextMate's, but I've had a few bugs with TextMate's tabs where they don't drop where you expect, or the tab bar gains "gaps" where closed windows leave spaces behind.</li> </ul> <p dir="auto">There are few things that seem to differ.</p> <ul> <li>Double-click on a tab to open in a new window. I seem to trigger this accidentally when clicking on a window to bring it to the foreground way more often than triggering it intentionally.</li> <li>Dragging a tab away from the tab bar with Apple tabs "tears off" the tab into its own window, similar to TextMate double-click. In TextMate, dragging a tab turns it into a thing which inserts "context dependent things" (e.g. entire file contents, file path, a Ruby 'require' statement) when dropped. This happens usually for me from a failed drag-to-reorder and the same feature is already available by dragging in a file from the File Browser anyway.</li> <li>Equally sized tabs with text truncation. This is IIRC how Apple tabs <em>used</em> to work until a couple of OS X versions or so ago; now they do the compression and expansion thing, which seems more helpful in a web browser but perhaps less so in a text editor. I'm on the fence. I did have a look at the Apple API docs to see if the application could choose the display style, but more on that below.</li> </ul> <p dir="auto">So what am I missing that makes OS X native tabs so bad compared to TextMate's? Doing all this dev work bespoke is surely gallant, but feels like it might be effort that could instead be spent elsewhere.</p> <p dir="auto">All this said - the API docs for Apple's tabs are a complete joke, to the point of utterly embarrassing. There is literally no documentation at all, beyond auto-generated lists of properties and methods with no descriptions of any kind whatsoever. Even more of a horror story for usability and consistency is the failure to update the HIG with any information on window level tabs; <a href="https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/tab-views/" style="color:#3983C4">https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/tab-views/</a> is a different thing entirely. There have been no documentation updates for this at all, at least, that I can find. This all comes from a company that used to set almost the gold standard in API design and documentation.</p> <p dir="auto">-- <br> TTFN, Andrew Hodgkinson<br> Find photos, software, music and more at my home site, Bandcamp and GitHub:<br> <a href="https://pond.org.uk" style="color:#3983C4">https://pond.org.uk</a> / <a href="https://pondnz.bandcamp.com" style="color:#3983C4">https://pondnz.bandcamp.com</a> / <a href="https://github.com/pond" style="color:#3983C4">https://github.com/pond</a></p> </div> </div> </body> </html>