Use native tabs

[tolmasky]

This bug is coming from #29, but that original idea there was simply to restyle the existing tabs to match "Safari's". This has since (potentially) grown into the larger project of replacing SubEthaEdit's custom tabbing facilities with AppKit's new built-in solution. As I'll explain further down, this has more implications than I originally thought, so I wanted to sync up and make sure this is something we actually want before going forward. For starters, I want to make sure that the goals I have in my head match up with those of everyone else, especially SubEtha's owners:

1. Modernize and ideally use the platform look-and-feel.

   This is the simplest (and IMO most important) goal, and is achievable by more means than using AppKit's native tabbing. We could simply restyle PSMTabBarControl for example.

2. Create a sustainable way of maintaining platform look-and-feel.

   The argument for using native tabs here is that now that macOS has its own tabbing mechanism, it is likely to subtly change on each major release, and thus create unbounded maintenance work to constantly keep SubEtha's style inline with those. This would be one of the stronger arguments in favor of using native tabs.

3. Support subtle current and future tabbing behaviors.

   Similar to the above, we don't want to have to play the "replicate" framework game of supporting every key-command and built-in behavior in a world where we choose to skin the tabs and give the user the expectation that they will work the same (such as macOS's "show all tabs" view).

4. Simplifying the code base

   IMO the least important reason to do this, but worth mentioning, that if it is possible to use less custom concepts and thus make the codebase more accessible to people that "just know AppKit", it can have inherent additional value.

That being said, I took the time yesterday to read up on macOS's tabs, and they are unfortunately 1) very poorly documented, and 2) IMO not ...ideally designed. For starters, the only place I actually found any substantial information was in this WWDC video (which has an attached transcript). There is nothing on the level of the old "document model architecture" docs or anything like that. If I am mistaken and simply missed this, please let me know!

Now on to the design. Apparently Apple's main goal here was to make tabs "magically just work" on unaltered macOS apps. So the feature goes to great lengths to not provide any additional modeling, and instead is a "grand illusion". Tabs do not share a window like in every other implementation I've seen. Instead, windows are considered to be in a group by the windowing system and the windowing system then only shows one of them at a time. To make a different tab the selected tab, you merely order that window front of the others in the group.

While this is certainly a neat trick, it, as far as I can tell, leaves very little room for future flexibility. For example, I predict it will be difficult to have a sensible project window architecture (unless we play along with this game and make every window in a project have its own sidebar of files, etc). I have no idea of the performance implications of going from a shared-views model of tabbing to a "duplicate everything" model as is implied here.

Basically, if the tabbing is highly simplistic, the AppKit model seems "painless", but potentially leaves you on your own after that. I personally am not particularly interested in project-management features (that's one of the reasons I like SubEthaEdit), but I am aware that others do strongly want them, so I feel it's important to flag this now.

[monkeydom]

First of all: Thanks for the great writeup!

Now on to my take on it:

Long term the default cocoa system will not be enough. But as far as I can tell, it should be possible to remove PSMTabBarControl and switch to it without any major regression. And I would see it as good step if it is done without removing any of the current tab adaptation layers. E.g. make sure to make the cut right and then have a future new way of putting multiple entities in a window in a good way in mind. E.g. the web preview and the plain text editor should be something modular we can independently put together in a good full screen experience.

So in short, I think this is worth exploring.

1. Remove PSMTabBarControl and switch to cocoa window tabbing with this issue (Use native tabs #43).

• Make sure to not regress anything important, and try to make it as nice as you can, including e.g. supporting the show x path components in window title feature in a way the tabs still read right (without modification it will trim from the right side and make the tab titles quite useless).
• Ensure to keep in potential abstractions for componetizing files and views in place (e.g. the somewhat crude but existing PlaintextWindowControllerTabContext)

2. As either a part of Project Context #1 or even separately create a leaner more modern and more flat abstraction to have different separate entities in a window.

Good to hear that you are not very eager on a project context, so I hope to get your input once I start tackling #1 so it does not negatively influence your workflow while still offering something to work with whole directory trees and git checkouts in a great way.

And to reference your points: 4) is quite high on my list for a long time sustainable code base. Simplyfying, reorganizing, keeping it clean has a high priority for me. And for that removing the dependency on PSMTabBarControl gains a lot of points.

[tolmasky]

Just wanted to give a quick update that I've been attacking this in my spare time and making some progress. I've also been looking at other apps that use macOS's native tabs, and I now feel that we may have more runway on that strategy than I originally though (in particular, xCode seems to use native tabs and do a full IDE).

[tolmasky]

Working through this, I have a question: does PlainTextEditor represent ONE text view? In other words, when you enable split mode, are you seeing two PlainTextEditors, or just one? And, if it is just one, then how do you get into a situation where a PlainTextDocument has more than one PlainTextEditor?

It appears that every document could have multiple window controllers (not sure how you can open two windows with the same document), which can each have multiple tabs, which each have multiple PlainTextEditors. Is it possible to actually have this situation? 2 windows, each with 2 tabs, all references the same Document, each with two PlainTextEditors themselves, thus resulting in 8 PlainTextEditors tied to the same document?

[tolmasky]

I see that I can do New View in new Window, but if I then try to merge windows, it recombines them. So so far, I know how to make two windows, each with 2 editors (if each split view gets 2 editors). But I do not know how to get two tabs two have editors pointing to the same document.