Migrate from PhosphorJS to Lumino

[sdirix]

What it does

Migrate from PhosphorJS to Lumino

PhosphorJS is no longer actively maintained for a few years now. Lumino is an active fork, maintained by the JupyterLab community.

While PhosphorJS proved reliable for a long time, the cracks are starting to show. For example we need to patch PhosphorJS to support secondary windows.

The JupyterLab community is welcoming and is open to accept contributions.

Contributed on behalf of STMicroelectronics

Current state

The PR is split into separate logical commits to make the reviewing and maintenance work easier in case the PR takes longer to complete.

This PR is a draft PR as not all known issues are yet fixed.

Open issues are:

• Tab bars currently have double the width than they should have (@tsmaeder)
• The "..." bar actions do not work (@tsmaeder)
• When shrinking the left view tab bar, the content is not adjusted (normally, we get a "..." when not all view tabs can be shown (@tsmaeder)
• When opening a diff editor (from the git changes view), the height of the editor tab bar is too big. When switching between editors before and after the diff editor tab, the height becomes correct sometimes (when switching from the one after the diff editor)
• The preferences tree does not react on selections (@tsmaeder)
• The preferences content does not scroll (@tsmaeder)
• Existing import and style changes update to latest code base (@sdirix)
• Fix CI checks (@sdirix)
  • license check
  • tests
  • playwright
• Optional as already broken in current master: linux-only: context menu of terminal and chat view in secondary windows are opened in main window. editor context menus however do work.
• non-native title menu behavior (@tsmaeder)
  • selecting a title menu (which opens the sub menu popup) and clicking again in the title menu brings the clicked on menu into a focus state. An additional click is now necessary to lose the focus before another menu can be opened.
  • Optional as already broken in current master: Selecting an element in a different pane (e.g. file explorer, or market place) and then interacting with the title menu is completely broken. Cause seems to be menu-dirty-changes, triggered by the focus change in parts.
• Editor autocomplete popup is misaligned (rendered too far away) (@tsmaeder)

If anyone is interested in solving one or more of these issues, contact me or open a PR against the lumino-migration branch in the EclipseSource fork.

This is a huge breaking change.

How to test

Build and test the application

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[tsmaeder]

selecting a title menu (which opens the sub menu popup) and clicking again in the title menu brings the clicked on menu into a focus state. Clicking any other menu item in the title menu next, will still open that focused menu.

@sdirix I don't understand what this does: can you give a more concrete example what you click on in what sequence?

[sdirix]

selecting a title menu (which opens the sub menu popup) and clicking again in the title menu brings the clicked on menu into a focus state. Clicking any other menu item in the title menu next, will still open that focused menu.

@sdirix I don't understand what this does: can you give a more concrete example what you click on in what sequence?

After the merge of the latest master state, the issue is now less severe: The focus state is still there, however it "just" prevents opening the menu and does no longer open the wrong one. I'll update the description in the overview text.

Focus State Issue

The issue only occurs in the non-native menu bar, i.e. in the Theia Browser variant or when disabling the native menu in the Electron case:

• Clicking on a menu and closing it again still focuses the menu item
• The next click does nothing besides losing the focus

This is how it works in the current Theia

File Explorer Interaction

This is already broken in current master, however it's worse on the current lumino branch because of the issue above:

• Click a file explorer item
• Click on the menu -> Nothing happens
• Click on the menu -> Nothing happens
• Click on the menu -> Only now does it open

In the current master we need two clicks to open the menu. In the lumino branch we need three clicks.

[tsmaeder]

It turns out the focus change causes the view part titles to change, which in turn refreshes the view container menu. This updates the visiblity toggle commands for that container. This in turn causes BrowserMainMenuFactory.showMenuBar() to invoked which replaces the whole main menu. This is happening while the menu is being shown, so the menu becomes empty. On the second try, the focused widget probably does not change anymore and the menu is shown O.K. When I remove the listener for the title change, the main menu bar works just as expected.

[tsmaeder]

Note that we need update the main menu when the menu registry changes, menus might have been unregistered and the main menu bar has no "onBeforeShow" obviously, as it is always visible. Dynamic menus for the main menu bar seem more and more a strange concept to me. Also putting local menu items like visibility of the views in a view part container into a global menu registry seems odd to me. Maybe we need a completely different approach here.

[sdirix]

@tsmaeder Thanks for the fixes! I tested it a bit and it's significantly better than before. There is one behavioral change though: The title bar menus can no longer be closed by clicking them again which seems a bit weird.