-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Initial implementation of a new 'lightweight' background-work-indicator that we can use in-situ in the editor. #59759
Initial implementation of a new 'lightweight' background-work-indicator that we can use in-situ in the editor. #59759
Conversation
Tagging @cdblake1 |
// controlling everything ourselves. | ||
_toolTipPresenter = factory._toolTipPresenterFactory.Create(textView, new ToolTipParameters( | ||
trackMouse: false, | ||
ignoreBufferChange: true, |
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.
Why turn this off, and handle cancelOnEdit
ourselves? Is it just not working yet?
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.
Primarily because when we handle it ourselves we go through our entire pipeline of steps (including cancel'ing the CTS for our operation). We don't have an effective way (that i could tell) to know that the tooltip was dismissed due to buffer change.
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 thought I remember seeing something on the spec, either an event, or a cancellation token that we could use (and created linked token from), but if not, then fair enough. I might have been looking at the V2 doc.
Integration tests showed a bunch of errors coming from this exception:
I'm guessing this PR updated dependencies to versions not supported by CI? |
Followup to #59802
The model of this closely follows (including at the API level) the IUIThreadOperationContext model the editor already has for CommandExecutionContexts.
Namely, an operation (like goto-def, add-using-on-paste, etc.) can startup and create such a context object to represent the work they do. However, instead of that context object being backed by a threaded-wait-dialog (TWD) (modal, heavyweight, focus-stealing), they instead get one effectively backed by a rich tooltip (non-modal, lightweight, doesn't affect focus) in the code where they started the operation. The UI for thsi tooltip is still a work in progress. However, you can imagine it saying things like
Navigating to definition (Esc to cancel)
with the options for things like progress to be shown using a thin progress-spinner like we have in many other parts of the IDE.Clients of hte IUIThreadOperationContext can treat it just like they would a TWD, adding scopes to it and setting the description/progress of sub-scopes. The tooltip will then batch up those changes and update the UI accordingly.
The indicator also tries to come with some batteries included. For example, it automatically hooks up to
Esc
being listened to to cancel the work it is doing. It can also auto-cancel on edits to the buffer (the default), or navigating away from taht doc (the default).Looks like this: