Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a multiline-line text input #780

Merged
merged 8 commits into from
Apr 5, 2023
Merged

Conversation

veler
Copy link
Collaborator

@veler veler commented Apr 1, 2023

Pull request type

Please check the type of change your PR introduces:

  • Bugfix
  • New feature or enhancement
  • UI change (please include screenshot!)
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Documentation content changes
  • Internationalization and localization
  • Other (please describe):

What is the current behavior?

DevToys 2.0 doesn't have a multi-line text input yet.

What is the new behavior?

Added a multi-line text input control that supports read-only and read-write mode.
Compared to DevToys 1.0, this time, every multi-line text input will use the Monaco Editor. This will help DevToys handling scenario where users paste very long text where we weren't necessarily expecting it.

DevToys 1.0 has a memory consumption issue related to Monaco: every time the monaco editor is needed, we create and allocate a new one. That means that when jumping from a tool that use Monaco to another that also use Monaco, we will now have 2 instances of Monaco (with 2 WebView) in memory. Each instances of Monaco consumes roughly 150 MB of RAM. This makes DevToys quickly consuming GB(s) of RAM.
In addition, loading the Monaco Editor is slow. It requires us to display a Progress Ring every time we open a tool for the first time that needs the editor.

In DevToys 2.0, we now use a pool of Monaco instances. Every time we jump from a tool to another, we will "release" the Monaco Editor that was in use in the tool, detach it from the UI. When navigating to the other tool, we will ask the pool to provide us an instance of Monaco. The pool will either provide an instance that got previously released, or produce a new one.

This way, when 2 tools need 1 Monaco editor, we allocate only one.
When navigating to the new tool, we change the text, language, settings of that Monaco instance we reused, so it adapts to the new tool. There might be a short time where we see the Monaco editor with a stale state, but in my opinion this constraint worth the gain of memory usage and loading speed of the tool.

This PR also address the following issues: #755, #494

Other information

Recording.2023-03-31.181010.mp4

Quality check

Before creating this PR:

  • Did you follow the code style guideline as described in CONTRIBUTING.md
  • Did you build the app and test your changes?
  • Did you check for accessibility? On Windows, you can use Accessibility Insights for this.
  • Did you verify that the change work in Release build configuration
  • Did you verify that all unit tests pass
  • If necessary and if possible, did you verify your changes on:
    • Windows
    • macOS (DevToys 2.0)
    • Linux (DevToys 2.0)

@veler
Copy link
Collaborator Author

veler commented Apr 1, 2023

Last commit added support of fonts. Here, Cascadia Mono is used after being detected as the best font to use.

image

image

Base automatically changed from dev/2.0-singleline-text-input to dev/2.0 April 1, 2023 14:40
@veler veler linked an issue Apr 2, 2023 that may be closed by this pull request
@btiteux btiteux merged commit 41a4874 into dev/2.0 Apr 5, 2023
@btiteux btiteux deleted the dev/2.0-multiline-text-input branch April 5, 2023 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants