Working prototype of new frame management

[bttelle]

• Added collapse, maximize and hide buttons and corresponding menu items to TabbedViews (Hide replaces close unless you really want to remove the DockingFrame)
• Keeps track of visibilty of TabbedViews when debugging separately from editing; the IDE will monitor for changes and save them. You can also use the tabview menu to fine-tune visibility for each mode.
• Expanded the serialization schema to support this.
• When closing a tab, the document is added to a recent list for the view. When it's opened again, the tab will be in the same place. Recent document lists are serialized so they still work if you close the session. If the view is collapsed or minimized it will be shown.
• When a view is collapsed, clicking on a tab will expand it. When a view is maximized, using the tab menu to select another tab will replace it as the current maximized tab.
• Maximizing views is a step-wise process until the entire MainWindow is covered. Maximizing a view hides sibling views.
• When you close a view using the X button or use the hide menu item; you can restore it by invoking one of the tabs contained through the main menu or using "show hidden" from one of the remaining visible tabview menus. It may also be restored automatically if you change from edit to debug or back.
• When you close the IDE the current visibility settings are retained. If you want a specific view to always be open when you load the IDE regardless of what views are loaded when you exit and save, you can change the "On Load" setting of the view in the tabview menu. The IDE merges the saved settings with the "On Load" settings at launch. In the menu if you click an already selected visibility setting iit will clear the setting override.
• It's intended that the user will create a new view containing the tabs that are useful in debugging (or editing) and use the view visibility tools to make them auto appear or close based on the mode. Individual tabs don't auto open if they're closed but they are at close reach in the recent tabs list for the view.

Known Deficiencies:

• Document frames that fill area don't always retain a reasonable size when maximizing/restoring other sibling views.
• Remove Frame doesn't always remove the frame completely (as "Close" used to).
• When you maximize a view that has collapsed siblings, it hides the collapsed tabview instead of maximizing up to the next level. Maximizing again will enlarge the view.
• Currently works with MainWindow ONLY; secondary external windows will come in a separate commit.
• When you make a view really small, the tab label gets smaller before the extra buttons for minimize/expand dissappear. Since the functionality is all on the menu it would make sense to eliminate the buttons before minimizing the tab label.
• Icons were chosen from the existing ones. Should probably tune them up.
• Closed tabs are kept in recent tabs; they could be auto-opened in specific modes. For now just the views auto-open.

[bttelle]

No rush to merge this. I can break it up into smaller pieces if you want. I will finish the multi-window stuff and resolve any review feedback this week. It works and has a lot of new functionality so anyone is welcome to pull this and try it out and let me know what you think!

[bttelle]

Showing the minimize/maximize/close buttons; collapsed tabs (Output) and the tab settings menu with the workspace tabview selected to Hide on Debug. As mentioned above, intead of using the menu, you could just close the Workspace tab while debugging and this setting will be applied for you.

[bfiete]

I'm going to get into this, but it probably won't be until next week.

[bfiete]

Some initial thoughts: The stepwise minimize/maximize behavior is neat.

For the settings menu, I think we can get rid of the parenthesized "state info" for "(documents)", "(permanent)". The checkmark itself is good enough, I think.

I'm not sure I understand the "On Load" concept. I was expecting to just see a setting for "Editor" and a setting for "Debugger". From a UI perspective it seems like those should be in their own named submenus and then get rid of the "On Load"/"On Debug" text to the right of the selected setting.

I think there's some missing functionality that may be important:

What if someone wants their editor set up like this:

And their debugger set up like this:

This requires:

1. Actual frame layout to be different based on mode
2. Splitter positions to be different
3. The 'Output' tab to be visible in both modes but other debug tabs within the same frame to be hidden

None of that works in this current model. Thoughts?

[xposure]

@beefy those screenshots would be my intended use case

[bttelle]

@bfiete I think there are two different ways to go with this. The current approach in this PR and the one you proposed where you freeze everything and say "this is the editor" frame and tab visibility configuration and totally separately "this is the debug" frame and tab visibility. What's implemented tries to keep whatever your current workspace is but then add or hide some things as needed either on debug or when you startup the editor (in case last session was irregular and hid some things). I implemented it this way because no other IDEs do (that I know of) as an experiment and it is more inline with how I work. Plus I intended there to be more than 2 states (build/error/source mgmt.. etc.) and when you get beyond two states saving everything exactly but with small differences is annoying when you decide you want to change things. Having said that I'm fine with implementing just two states and serializing everything needed to toggle between the two to get your exact behavior above if that's what folks want. Agreed on your other minor points.

[bttelle]

Also responding to your points:

1. Frame layout can be different but only through hiding in the current PR so that does constrain things
2. Splitter positions would have to be serialized separately (they aren't now)
3. Hiding/Showing specific tabs was on my NIY list above

So in sum you could get close but it may be too diferent from what folks are used to. I'll get back to implementing this on the weekend.

[bfiete]

Your approach was novel, and I think it was a good first stab, but the screenshots actually do represent my own use case, so I would want to support that.

We could still support more than two layouts - we could allow users to define their own layout types and provide facilities for switching between them.

Should we be serializing layouts on a per-workspace basis or just make singly globally-serialized layout? Hm.

[bttelle]

Once it's all working it's trivial to load per-workspace or globally. Probably best to allow both. You definitely should be able to save a global layout pair (edit/debug) and allow the user to select that if workspaces get stale vs your hw config.