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

Add preference for visualPreview on hover #12648

Merged
merged 6 commits into from
Jul 27, 2023

Conversation

sgraband
Copy link
Contributor

What it does

Made window.tabbar.enhancedPreview an enum preference with these options:

  • classic: a simple unstyled preview, containing the name
  • enhanced: a styled preview containing title and caption (Add extended tab bar preview option #12350)
  • visual: the enhanced preview + visual preview of the view Extended the hover service so that it supports the visual preview.

Added the PreviewableWidget interface.
Widgets, implementing this interface, can be previewed once they were loaded. The loaded flag is set to true when a widget is set to active. Widgets implementing the interface can specify how the preview should look like. The default is simply the node of the widget.
Webviews are currently not previewable, as they raise some challenges. For example, scripts in the webviews would need to be handled/blocked. Therefore, an approach for webviews should be tackled in a follow up.

Fixes #12646

Contributed on behalf of STMicroelectronics

How to test

  1. Check out this PR an open Theia
  2. Set the window.tabbar.enhancedPreview preference to visual
  3. Observer, that on horizontal tab bars when hovering a tab of a view, that is currently not visible, but was loaded before, a visual preview is rendered in the hover feedback.

Review checklist

Reminder for reviewers

@sgraband
Copy link
Contributor Author

@vince-fugnitto Could you review this? Since you reviewed the previous PR (#12350)?

(I will resolve the Changelog conflict together with any review feedback ;))

Copy link
Member

@vince-fugnitto vince-fugnitto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the contribution, I've noticed a couple of things:

  • the feature does not work well with different layouts, and often hides the visual hover
  • the styling of the visual preview can be enhanced to have a more fixed width so it is consistent for different tabs and for different nested files (at the moment the size is quite big and hides a lot of information as opposed to the ones present in the browser, and depending where a file is located will differ in size giving an odd user-experience)

image

image

packages/core/src/browser/core-preferences.ts Show resolved Hide resolved
packages/core/src/browser/core-preferences.ts Outdated Show resolved Hide resolved
packages/core/src/browser/widgets/previewable-widget.ts Outdated Show resolved Hide resolved
@vince-fugnitto vince-fugnitto added proposal feature proposals (potential future features) core issues related to the core of the application ui/ux issues related to user interface / user experience labels Jul 6, 2023
@sgraband
Copy link
Contributor Author

Thank you for the feedback @vince-fugnitto! I will take a look at the styling and the comments you mentioned.

@sgraband
Copy link
Contributor Author

@vince-fugnitto I added three commits:
ea5397a addresses your minor feedback in the comments.
39be6ce fixes the aspect ratio of the preview windows to 16:9. This should help to unify the hover experience between views.
b30b06f fixes a small bug with the title and caption so that they acknowledge the max-width of the hover.

I am not sure, if the width problem should (or needs to) be solved with this PR. The way it is now, adaptors can set the --theia-hover-max-width css variable to the maximum width they like for the hover. The visual preview takes this max-width into account. And with the latest commit, as mentioned before, the caption and title will also acknowledge the max-width. So this is already customizable, but maybe could be improved in the future via a preference for example.

Could you take a look at the changes and tell me what you think?

@vince-fugnitto
Copy link
Member

I am not sure, if the width problem should (or needs to) be solved with this PR. The way it is now, adaptors can set the --theia-hover-max-width

@sgraband my comment was more for the default user-experience and not so much the customization for downstream adopters. At the moment, depending on how long the file-path is, the preview will differ in size for different files which gives off a bad user-experience. As the default I believe that previews should have a standard size, and downstream can customize if they want to (this is similar in behavior to browser previews which the feature is inspired by).

preview-irregular-sizes.mp4

@sgraband
Copy link
Contributor Author

@vince-fugnitto I changed the max-width variable to a simple width one and fixed the value to 300px. Let me know what you think.

@sgraband
Copy link
Contributor Author

@vince-fugnitto would you have time to take another look this week? I will be out of office next week, so it would be great to have some feedback this week. TIA

@@ -17,7 +17,7 @@
/* Adapted from https://github.com/microsoft/vscode/blob/7d9b1c37f8e5ae3772782ba3b09d827eb3fdd833/src/vs/workbench/services/hover/browser/hoverService.ts */

:root {
--theia-hover-max-width: 500px;
--theia-hover-width: 300px;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is another breaking change that adopters might depend on?
I don't think there is harm in keeping both variables (one for width and one for max-width).

@@ -27,7 +27,7 @@
background-color: var(--theia-editorHoverWidget-background);
border: 1px solid var(--theia-editorHoverWidget-border);
padding: var(--theia-ui-padding);
max-width: var(--theia-hover-max-width);
width: var(--theia-hover-width);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change actually breaks other hovers we have in the framework (ex: statusbar).
Can we instead only style the enhanced preview with the proper width and not update the more generic theia-hover:

statusbar-hover.mp4

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! I reworked the last commit, so that both variables are there, but the --theia-hover-preview-width variable is only used by the preview hovers.

@sgraband sgraband force-pushed the visualPreview branch 2 times, most recently from f77f965 to 00f3a90 Compare July 25, 2023 15:19
Copy link
Member

@msujew msujew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to work pretty well. I noticed some unexpected behavior when the widget has been stretched across the screen, see here. However, I believe that's due to the general approach of re-rendering the widget in another HTML element, and cannot be easily addressed. It might also just be me, I've been hoping that the preview shows more than what is rendered in the widget itself.

Anyway, aside from that I just have a minor comment. Otherwise this looks pretty good 👍

packages/core/src/browser/shell/tab-bars.ts Outdated Show resolved Hide resolved
Made window.tabbar.enhancedPreview an enum preference with these options:
- classic: a simple unstyled preview, containing the name
- enhanced: a styled preview containing title and caption (eclipse-theia#12350)
- visual: the enhanced preview +  visual preview of the view
Extended the hover service so that it supports the visual preview.
Added the `PreviewableWidget` interface.
Widgets, implementing this interface, can be previewed once they were loaded.
The loaded flag is set to true when a widget is set to active.
Widgets implementing the interface can specify how the preview should look like.
The default is simply the node of the widget.
Webviews are currently not previewable, as they raise some challenges.
For example, scripts in the webviews would need to be handled/blocked.
Therefore, an approach for webviews should be tackled in a follow up.

Fixes eclipse-theia#12646

Contributed on behalf of STMicroelectronics
Adjust changelog and preference description

Contributed on behalf of STMicroelectronics
This way the size of the previews is more uniform.
If the view is wider than 16:9 the scaling is according to the width.
If the view is longer  than 16:9 the scaling is according to the height.
The other dimension is then cropped.

Contributed on behalf of STMicroelectronics
Before the two fields ignored the max-width.

Contributed on behalf of STMicroelectronics
Contributed on behalf of STMicroelectronics
Contributed on behalf of STMicroelectronics
@msujew msujew merged commit 002fd17 into eclipse-theia:master Jul 27, 2023
@vince-fugnitto vince-fugnitto added this to the 1.40.0 milestone Jul 27, 2023
kittaakos pushed a commit to arduino/arduino-ide that referenced this pull request Sep 14, 2023
kittaakos pushed a commit to arduino/arduino-ide that referenced this pull request Sep 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core issues related to the core of the application proposal feature proposals (potential future features) ui/ux issues related to user interface / user experience
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Provide visual preview for widgets
3 participants