an option to collapse a column/strip and un-collapse it later

"Visual Studio Code" is obviously a trademark, so Visual Studio CodeRibbon would likely step too far into Microsoft's ownership territory.

Taking suggestions for application names, right now the default will likely just be "CodeRibbon", but it's not the best because there are multiple implementations of CodeRibbon.

Extra controls that appear when the pane is active need to be overwritten / replaced or just removed altogether to make room since they will not function after VSCR changes.

being able to pop this into a patch below would be more handy than the default action of opening a new editor on the peeked file

Elements such as autocomplete suggestions or documentation hovercards need their logic updated to work depending on if their hierarchy in the DOM causes their positioning to be offset from the Ribbon Container or from the Ribbon itself.

Figure out the best way to override the theiaDockPanel that's by default placed in the shell's mainPanel in the default FrontendApplication.

RibbonPanel needs to implement or stub all missing features from TheiaDockPanel and DockPanel, while it it self extends BoxPanel, which unfortunately is mostly incompatible with DockPanel layouting.

We could embed the class/function breadcrumbs in addition to the file name and path if there's room in the title of a patch. Just have to make sure there's still enough room to use it as the grab handle.

The Ribbon components want to derive BoxPanel instead of the DockPanel like TheiaDockPanel does, however the phosphor BoxPanel is not feature-complete to DockPanel.

• Close patch
• Close Column
• Split patch:
  • Left
  • Right
  • Up? (do people use this, is there a reason?)
  • Down
• Move column or patch: (swapping, only displayed when possible? e.g. at top/bottom/left/right edges)
  • column right/left
  • patch up/down
• New:
  • patch above/below
  • column left/right

I realize nobody ever actually used "split patch up" in all my testing... maybe just remove it? It's basically the same result as down.

Autocompletion, documentation, etc... need to be hidden on overview and re-shown on exit (assuming the active patch was not changed)

We should have a section in the settings for the VSCR specific items and also remove settings that break the ribbon.

Tracking eclipse-theia/theia#6501

Doesn't look like https://github.com/jupyterlab/lumino includes any of the CR-required additions like save/restore layouts for non-Dock types of panels, think they'd be interested in those features getting upstreamed? Also still need to investigate if it's any better at providing drag/drop/hover/data events than the current phosphor.

IBL/IBP and similar might even be classified as upstreamable, not sure who else would use them yet though.

Perhaps both? Once clears, second (if empty) destroys?

https://github.com/eclipse-theia/theia/blob/v1.29.0/packages/core/src/browser/shell/application-shell.ts#L604

getLayoutData still contains unserialized widgets, so conversion happens outside the application-shell scope, therefore we need to be compatible enough with DockPanel that the outer code behaves the same.

https://github.com/eclipse-theia/theia/blob/v1.29.0/packages/core/src/browser/shell/shell-layout-restorer.ts#L156

getLayoutData from the AS is called by restorer

deflate: https://github.com/eclipse-theia/theia/blob/v1.29.0/packages/core/src/browser/shell/shell-layout-restorer.ts#L191

Assumes property names must match exactly widget or widgets by isWidget(s)Property...

Widget itself if stateful should provide storeState(), but looks like CR Patches will mostly be subject to the widget manager's whims: https://github.com/eclipse-theia/theia/blob/v1.29.0/packages/core/src/browser/widget-manager.ts

So in the end maybe a patch should not be reported as a first-class widget? (We could dig into it via our own serializer)

Same functions as Atom implementation.

VSCodeRibbon needs to have at least a little bit of information added to the website ( https://utk-se.github.io/CodeRibbon/ ) so people know what the actual longer-term plans are.

Also will probably involve adding a short/micro blog to the site for general CodeRibbon updates in either implementation. (Plus is a good venue to allow for more user comments on development ideas.)

BoxPanel needs resize handles added akin to DockPanel, probably time for a RibbonStrip subclass.

Something that still was never properly implemented in the Atom version.

View > Editor Layout has a lot of incompatible options that should either be rewritten to change Ribbon construction or just removed.

Need to take a look into the serializer to see if it's possible to write a custom dataset for strips dropped off the left edge of the ribbon to preserve system memory.

This would be the first layer of the Ribbon component

https://phosphorjs.github.io/phosphor/api/widgets/classes/boxpanel.html

Might be BoxLayout depending on user-facing functionality. This first layer is intended to only be modified by CR, unlike Panels which might imply user-draggable widgets.

CR's most used feature is probably the fuzzy open in blank patches, Atom already had the index of the project files, need to find where VSCode stores it's list that can be matched against.