I really like this idea! It makes sence to open submodules in tabs. This could even be the default..

I am not one of the projects owners and don’t want to act like one, but here are some thoughts:

Context menu support
Currently we only get this by double clicking, pressing alt while showing the context menu would be nice. Something like „Open submodule in tab“ as an alternate menu item.

Animation on open
When opening the new tab, we get the default document based app animation when opening a new window. It would be nice if the window was not closed for a split second.. I am not sure if this is possible..

Default behavior
This is more of a general question. What should be the default behavior when opening a submodule?
No matter what, the other way should be available through pressing option.

Again, I am not in charge here so don’t take my comment too seriously 😉

I agree that a context menu entry would be nice, and also about the not-so-nice animation right now.

However, I'm not experienced enough a Mac developer to do these things. I intentionally kept my PR small and isolated enough to remain mostly confident the patch will not break other things ;-)

Of course I'd like to see full tab vs windows support, not only for submodules. Also for "Open recent" it would be nice to just press option to open in a tab instead of a separate window. I often use groups of repos that are not necessarily submodules. It's just a bit over my head to actually implement all this myself...

There is a global OS-wide option for this. (I found it after getting annoyed with Sourcetree opening new windows.) It's in System Preferences -> Dock (obviously; Apple intuitiveness at work) -> Prefer tabs when opening documents -> Always.

It works ok but I still think individual apps should have this setting because it makes some non-native apps behave weirdly (e.g. in Eclipse-based apps dialogs now open as tabs - yes I know... Eclipse... but still).

@Timmmm very interesting - didn't know that. Did you find out what the "manually" setting does?

However I certainly can't switch that on globally only for the very specific case of opening submodules in GitX ;-)

So I still hope this PR eventually gets merged.

Sorry for the long turn-around 😟. To be frank, I'm not sold on adding tabs to the UI, because I don't think they're worth the UI weight for the usability they bring (they'd have to grab two shortcuts to move between them cough ⌃⇥ cough, and I'd prefer those to go to back/forward).

@tiennou thanks for the comments! I know, the opinion on the value of tabs varies a lot. But tabs are there already for any multi-document app at the macOS window manager level. It would take extra work to suppress them in Gitx.
The only goal of my PR was to enhance the workflow for those people who do use tabs (like me - definitely tabs are a huge improvement for my use cases!) a tiny bit. @mangerlahn had a few extra ideas which would put more focus on tabs - while I would not object those from my point of view as nice additions, I can survive well without ;-)
So I hold up my original PR which only changes the behaviour when option-doubleclicking a submodule in the sidebar and nothing else. For those that do use tabs, this improves gitx a lot, everone else will most likely not even notice it.

As I said, I'm not that sold on tabs, and I feel like they should at least be part of a more expansive rework of the GUI, instead of just a quick fix for submodules (I'm not even sure what the responder chain looks like when tabs get enabled, and its current state is already concerning as it is).

There are things that I'd (personally) like to get polished before tackling UI-things — though I'm now looking at a not-uniformly-dark-GitX window, so we'll see 😒…

Ok, your choice ;-) Feel free to close the PR.
So it'll remain my own little addition I need to add before I build my GitX, until tab handling can be part of a more expansive UI rework. Having this option is one of the nice things in Open Source...

Still, one last comment, because your reply sounded like tabs as such were something requiring action to add to or enable in GitX. I guess you know it, but for general clarity of this discussion for everyone (also because I myself only accidentally discovered it with GitX): Tabs have become a part of all multi document apps, including GitX, with macOS Sierra - without requiring a single line of code in the application itself. Because Apple has implemented tabs in a way nearly completely transparent to the app's code - for an app, a tab is just like another document window.

So all you need to "enable" tabs in GitX (or any other document based app) is choosing Show Tab Bar from the View menu...

Yeah since GitX does have tabs already I think this would be worth merging.