[txmt-dev] Re: Split Views Implementation

[Steven Clukey]

On Jan 2, 2015, at 6:50 AM, Jacob Carlborg <doob at me.com> wrote:

> This is awesome :D.
> 
> I few comments:
> 
> * I noted there are some issues with synchronizing the tabs and the content. If I open a file from the file browser it will open a new tab, show the correct content but the previous tab is selected. If I open another file the tab for the last opened file before that is selected. This is when no split view is active
> 

I’m surprised I didn’t notice this, but I guess that goes to show just how often I use the file browser. Fixed in new commit.

> * When there's a vertical split and TextMate is not the active application, the left border of the gutter is gone. The same thing happens for a horizontal split but for the bottom border of the status bar
> 

I don’t quite know what you mean here. I don’t see anything change, but I suppose I am just missing it. Could you provide a picture of what you are talking about?

> * It would be nice to have hotkeys for splitting and switch between the splits

There were already hotkeys for changing between splits, ⌃⌘{ and ⌃⌘}. I have added hotkeys for creating and removing splits in a new commit. I had to get a little long with them to avoid conflicts with bundles.

Split Horizontally: ⌥⇧⌘D
Split Vertically: ⌘D
Remove Current Split: ⌃W
Remove Other Splits: ⌃⌥W

> 
> * Personally I think the way you implemented the split view is a bit confusing. If there are two tabs open and one split. Each file is show in one view of the split. I would expect clicking a tab would active the corresponding split view, not chaining the content in the current split view.
> 
> Alternatively implement separate split views for each tab, this is how both iTerm and Xcode work.
> 

Perhaps I should explain a bit more why I implemented it the way I did:

The main concerns that drive the implementation are that it should be flexible (allow splitting the same document, arbitrary split locations, etc.) and at the same time be minimally invasive to the existing code. I believe that these goals are fairly well achieved as most of the code changes (and definitely the major ones) are contained to DocumentController and the new class, and splitting is quite flexible and easy.

Implementing the tab bar the ways you suggest would infringe on one or both of these concerns. Just making the tab bar select the split with that document open would make it tedious to split a single document and confuse what happens on opening and closing documents. Putting multiple tab bars (one for each split) would require much more refactoring of the code to make it work, this is doable, but unwanted. It also makes managing the splits and locations of the documents quite a chore (need to open documents in each split as if they are different windows, so they might as well be different windows).

Anyway the way it’s done here is not unprecedented in the editor world (QtCreator is similar), and I believe it would make sense to a person brand new to split views, so I don’t think the usability is an issue with this implementation.

Steven Clukey