Splitview

[Wouter01]

Description

This PR adds splitview support for the editor. It includes the following features:

• Ability to split editor vertically or horizontally, by right clicking a tab or by pressing the split button in the tab view.
• Translucency for the toolbar
• Translucency for the statusbar
• Improvements to terminal dragging
• Forward / Backward funcionality for each TabGroup
• Closing a TabGroup by pressing the X button
• Probably some other things I forgot

There are also some regressions, which will be addressed in a later PR:

• Terminal state is not saved
• Tab state is not saved
• TabGroup state is not saved

Related Issue

#338
#1109

Checklist

• Multiple Editors
• Horizontal Split View
• Vertical Split View
• Nested Split View
• Create Split View by right clicking on tab
• Create Split View by dragging file into editor
• Move tab to other editor by dragging
• Make top editors go under toolbar
• Make bottom editors go under bottom toolbar
• Adjustments to tabs
• Refactor WorkspaceDocument and others to support multiple tabgroups
• Fix UI issues
• implement close / backward / forward buttons
• Add support for temporary tabs
• Add menu when long-pressing forward/backward icon

• I read and understood the contributing guide as well as the code of conduct
• My changes generate no new warnings
• My code builds and runs on my machine
• I documented my code
• Review requested

Screenshots

[bombardier200]

@Wouter01 was just testing this out, it seems that the bottom drawer no longer allows you to select Debugger or Output, not for sure if this on purpose or not!

[Wouter01]

@Wouter01 was just testing this out, it seems that the bottom drawer no longer allows you to select Debugger or Output, not for sure if this on purpose or not!

Must've messed something up there 😅, I'll have a look

[Wouter01]

@Wouter01 was just testing this out, it seems that the bottom drawer no longer allows you to select Debugger or Output, not for sure if this on purpose or not!

Looks like there was no code for those yet? There was however an unused switch, which I probably removed

[austincondiff]

After thorough testing, I cannot reproduce any of my previously reported bugs! 👏

Way to go @Wouter01, great work. What an accomplishment! 🙌

[thecoolwinter]

A couple things beyond the comments I've left:

• There's a regression in the native tab style. The tab background is the active tab color and tabs consume the entire tab area when opened. See screenshots:
  Before:

After:

The background color also is the active color if you scroll to the left or right.

• After clicking the back and forward arrows of an inactive split, it doesn't bring the inactive split into focus. This looks like it's a quick fix by just setting tabManager.activeTabGroup in those button handlers.

[austincondiff]

A couple things beyond the comments I've left:

• There's a regression in the native tab style. The tab background is the active tab color and tabs consume the entire tab area when opened. See screenshots:
  Before:

After:

The background color also is the active color if you scroll to the left or right.

• After clicking the back and forward arrows of an inactive split, it doesn't bring the inactive split into focus. This looks like it's a quick fix by just setting tabManager.activeTabGroup in those button handlers.

@thecoolwinter I actually don't mind a single tab taking up the full width, two tabs taking 50% of the width, etc. This is how they work in Finder and every other app that supports native tabs. However, there is a slight problem, when there are no tabs, it looks like there is one big empty tab in the tab bar. It should instead be the darker background color behind the buttons.

Also when using native tabs, the vertical split line goes all the way up into the toolbar...

[Wouter01]

Thanks for the feedback! I'll try addressing the issues.

I wanted to touch on this:

• There's a regression in the native tab style. The tab background is the active tab color and tabs consume the entire tab area when opened.

I've checked, and it looks like that behavior is also there on the latest release of CodeEdit, so I'm guessing the change must've been made earlier. That said, I did make a regression regarding the color of the tabbar when no tabs are present, as @austincondiff pointed out.

[austincondiff]

@Wouter01 One additional thing I just found, after clicking the back and forward arrows of an inactive split, it doesn't bring the inactive split into focus.

[matthijseikelenboom]

Looks good to me, just fix @thecoolwinter 's comments and then it can be merged I think.

[Wouter01]

@Wouter01 One additional thing I just found, after clicking the back and forward arrows of an inactive split, it doesn't bring the inactive split into focus.

@thecoolwinter mentioned that too, it's fixed!

[austincondiff]

Approved, for the last time! After this I am not approving again... 😜

[thecoolwinter]

Looks good. This is a lot of work nice job!