-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Conversation
@vince-fugnitto Could you review this? Since you reviewed the previous PR (#12350)? (I will resolve the Changelog conflict together with any review feedback ;)) |
There was a problem hiding this 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)
Thank you for the feedback @vince-fugnitto! I will take a look at the styling and the comments you mentioned. |
@vince-fugnitto I added three commits: 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 Could you take a look at the changes and tell me what you think? |
@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 |
@vince-fugnitto I changed the |
@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; |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
f77f965
to
00f3a90
Compare
There was a problem hiding this 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 👍
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
Otherwise, the `title` is missing. Ref: eclipse-theia/theia#12648
Otherwise, the `title` is missing. Ref: eclipse-theia/theia#12648
What it does
Made window.tabbar.enhancedPreview an enum preference with these options:
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
window.tabbar.enhancedPreview
preference tovisual
Review checklist
Reminder for reviewers