Prune ide-desktop package

[vitvakatu]

Pull Request Description

Closes #13501

• ide-desktop/client moved one directory up, to app.
• Icons generator removed, app icons committed to the repository
  • .ico for Windows
  • .icns for Mac & Linux (Linux needs to be checked, but it should work according to documentation
  • .svg added as a “source” of the current icon, so we can adjust it in the future if needed.
  • MacOS Tahoe will use .icon format, but it is not yet supported in the electron-builder—we must wait before adding it as well.
• Electron app CLI simplified and reduced
  • Removed all unused parameters and flags (I mean literally unused, no code to handle them)
  • Removed many parameters that seem not useful and weren’t reported as used by anyone in the team. It includes performance-related Chrome flags and custom Chrome flags in general, window dimensions, and “inverted” flags such as --engine. Only --no-engine was used, so only it stayed.
  • Removed a bunch of complex code to define config options, load them from JSON, merge them together, type them with Typescript. A much simpler system is implemented, where we still have typed nested config objects, but parsing and validation is done with Zod, and we can flatten/unflatten it into a simple key-value list. lib/js/runner package was removed.
  • Removed duplication of config options in project-view. Before, we defined the same options twice—once in client, then in project-view as URL parameters. We also had duplication of lib/js/runner code inside project-view to parse this configuration from JSON.
  • commander.js used instead of yargs for mostly technical reasons—configuring yargs to work well with the new logging system was a very confusing experience. commander.js is simpler and has a slightly smaller bundle size, but the main reason it was simpler to integrate.
• vibrancy feature is removed.
• New application-wide logging system.
  • Overwriting most console.* methods—it does not require changing existing code, and also does not require remembering to import logging stuff everywhere.
  • DevTools console messages are forwarded to the stdout of the Electron app. Keep in mind that some messages will not appear there—for example, failed network requests. But most of the other stuff will be forwarded.
  • In the Electron app, console.* methods are now used for logging. It gives unification with the GUI code. Some complex mechanics like grouped messages and timing recordings were removed—I didn’t find enough code to justify supporting them.
  • As before, all stdout messages (including those forwarded from DevTools) are also saved to the local log file in the filesystem. On Mac, it is /Library/Logs/enso. According to Electron documentation, it would be the “userData” directory on Windows and Linux. e.g. @farmaazon found his logs somewhere inside ~/.config.
  • Terminal colors support was removed—it only mangles the log file and complicates the implementation.
• Removed duplication of code between globals.d.ts and env.d.ts files.

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[vitvakatu]

So I found out that Linux CI failures in package tests were caused by misconfiguration of Chrome flags.
Passing --disable-dev-shm-usage fixed the issue, but we were not using this flag before. It turns out I forgot about some Chrome flags when moving the code around, and that’s why tests started failing in CI.

Looking at the list, I don’t think we need all of them, though:

• disable-gpu-sandbox: true
  Disable the GPU process sandbox to avoid WebGL crashes on some configurations.
• disable-gpu-vsync: true
  Disable GPU vertical synchronization to reduce latency and improve performance on weaker hardware.
• disable-smooth-scrolling: true
  Disable smooth scrolling to reduce input latency.
• enable-native-gpu-memory-buffers: true
  Enable native CPU‑mappable GPU memory buffer support (primarily for Linux). This one missed is the most likely cause of failure on CI.
• force_high_performance_gpu: true
  Force using the discrete GPU when multiple GPUs are available.
• ignore-gpu-blocklist: true
  Override Chrome’s blocked GPU list to allow GPU acceleration on otherwise blocked hardware.
• backgroundThrottling: false
  Do not throttle animations/timers when the window is in the background.

@kazcw @farmaazon @Frizi do you think we can safely remove some of these flags?

[kazcw]

So I found out that Linux CI failures in package tests were caused by misconfiguration of Chrome flags. Passing --disable-dev-shm-usage fixed the issue, but we were not using this flag before. It turns out I forgot about some Chrome flags when moving the code around, and that’s why tests started failing in CI.

Looking at the list, I don’t think we need all of them, though:

* disable-gpu-sandbox: true
  Disable the GPU process sandbox to avoid WebGL crashes on some configurations.

* disable-gpu-vsync: true
  Disable GPU vertical synchronization to reduce latency and improve performance on weaker hardware.

* disable-smooth-scrolling: true
  Disable smooth scrolling to reduce input latency.

* **enable-native-gpu-memory-buffers: true**
  Enable native CPU‑mappable GPU memory buffer support (primarily for Linux). This one missed is the most likely cause of failure on CI.

* force_high_performance_gpu: true
  Force using the discrete GPU when multiple GPUs are available.

* ignore-gpu-blocklist: true
  Override Chrome’s blocked GPU list to allow GPU acceleration on otherwise blocked hardware.

* backgroundThrottling: false
  Do not throttle animations/timers when the window is in the background.

@kazcw @farmaazon @Frizi do you think we can safely remove some of these flags?

I would think we can remove all of these. They were needed due to the specific characteristics of GUI1, but GUI2 is much more of a typical web app, and the Chrome defaults are probably more appropriate.

[vitvakatu]

Interesting, enable-native-gpu-memory-buffers alone is not enough: https://github.com/enso-org/enso/actions/runs/18281115196/job/52047106903

GitHub

Prune ide-desktop package · enso-org/enso@6682b87

Enso Analytics is a self-service data prep and analysis platform designed for data teams. - Prune ide-desktop package · 6682b87

[vitvakatu]

enable-native-gpu-memory-buffers + ignore-gpu-blocklist seems to be fixing the issue. Why? No idea.

[vitvakatu]

Ok, I think it is ready to be merged. I will create separate issue for investigating shared memory issue on Linux runners.

[vitvakatu]

Merging it sooner than later to avoid further merge conflicts. Feel free to review and leave comments