-
Notifications
You must be signed in to change notification settings - Fork 83
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
Show a progress indicator when opening a PDE run configuration. #674
Show a progress indicator when opening a PDE run configuration. #674
Conversation
Test Results 264 files ±0 264 suites ±0 51m 2s ⏱️ - 1m 56s For more details on these failures, see this check. Results for commit 8d12915. ± Comparison against base commit d551a60. ♻️ This comment has been updated with latest results. |
With this change now always the progress-indicator pops when opening the launch-configuration Editor, even if it is just for a very short time. |
447c930
to
afc0dca
Compare
I made some changes and shifted all the heavy lifting to the activation of the Tracing tab, so I managed to get rid of the dialog at the beginning. The problem with the flickering still remains, but it now happens while changing some of the configurations in the Tracing tab and the flickering happens in the lower part of the Run configurations... dialog (in the progress bar). The good thing is that fixing that is easier than fixing the dialog, here's a draft PR to do that --> eclipse-platform/eclipse.platform#591 |
3159f64
to
d0bfdb8
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.
I looked into this and as written below an additional cache seems not to be necessary.
But shifting the first call to the TracingManager seems reasonable.
I suggest we add a method to TracingOptionsManager
like ensureInitialized()
that basically calls getTracingTemplate() and passes a ProgressMonitor
to it so that we can at least see progress. It shouldn't be canclable because otherwise the state would become inconsistent or more complex to manage.
I'm currently working on a greater clean up of many of the launcher classes, which would also make the TracingOptionsManager a bit simpler. Maybe you want to await that before adding the suggested ensureInitialized()
method, in order to avoid conflicts.
ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/launcher/TracingBlock.java
Outdated
Show resolved
Hide resolved
👌 |
Since #755 is now submitted, we can continue on this one. :) |
Thinking about it again, a To achieve this it is probably sufficient to replace
and pass just null as monitor in all other callers of |
Call handleTabSelected right after displaying all tabs in the LaunchConfigurationTabGroupViewer::displayInstanceTabs so that the "activated" method of the tab is called. Contributes to eclipse-pde/eclipse.pde#674
68ce965
to
a11dd95
Compare
@HannesWell I just pushed some changes and took your advice about using the
Edit: additional changesI did not make the tasks/monitors cancelable for now because that requires to rethink how the UI behaves once the task has been canceled (probably some elements need to be disabled) and also where to handle the proper exceptions in the code. I'd like to leave that for a future PR since these changes already provide a good enough performance and usability improvement even without the task being cancelable Important: do NOT merge yetThis PR is blocked by eclipse-platform/eclipse.platform#766 |
Test failure already documented here: #820 |
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 made some adjustments though:
* I didn't add any method to make sure the template is initialized ( _e.g._ `ensureInitialized`) because I had no need for it * I inverted the `if`-logic in the method to reduce the [cognitive complexity (nesting level)](https://docs.sonarsource.com/sonarqube/latest/user-guide/metric-definitions/).
That's fine.
* I converted the stream into a `for`-loop to properly report the progress since one needs to call `monitor.split(1)` for every model and not for every _filtered_ (non-null) model.
Good catch!
I did not make the tasks/monitors cancelable for now because that requires to rethink how the UI behaves once the task has been canceled (probably some elements need to be disabled) and also where to handle the proper exceptions in the code. I'd like to leave that for a future PR since these changes already provide a good enough performance and usability improvement even without the task being cancelable
Sounds reasonable. If you one day make it cancalable, the Tracing-tab could look similar to the disabled tracing state, but the Enable tracing
check-box state should not be affected by that. The editor could then contain a button instead to load the tracing options again.
With the mentioned changes this would be perfectly ready from PDE side.
This PR is blocked by eclipse-platform/eclipse.platform#766
I'll try to participate there over the weekend.
ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/TracingOptionsManager.java
Outdated
Show resolved
Hide resolved
ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/launcher/TracingBlock.java
Outdated
Show resolved
Hide resolved
ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/PDEUIMessages.java
Outdated
Show resolved
Hide resolved
ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/PDEUIMessages.java
Outdated
Show resolved
Hide resolved
fRunnableContext.run(true, false, monitor -> { | ||
SubMonitor subMonitor = SubMonitor.convert(monitor, taskName, 1); | ||
result.putAll(task.apply(subMonitor.split(1))); | ||
}); |
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.
It would be nice if there would be some kind of ICallableWithProgress
.
ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/launcher/TracingBlock.java
Outdated
Show resolved
Hide resolved
Call handleTabSelected when switching to a new run configuration so that the "activated" method of the tab is called. Contributes to eclipse-pde/eclipse.pde#674
Thank you! I'll keep that in my for the next PR :-)
Thank you! |
a11dd95
to
9fe6dc6
Compare
9fe6dc6
to
970130a
Compare
8f47de8
to
6a39932
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.
Thanks for the adjustments.
I just have two non-critical remarks and then this is ready from the PDE site.
ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/launcher/TracingBlock.java
Outdated
Show resolved
Hide resolved
ui/org.eclipse.pde.ui/src/org/eclipse/pde/internal/ui/launcher/TracingBlock.java
Show resolved
Hide resolved
6a39932
to
f8d18e2
Compare
Don't start unnecessary operations that only concern the "Tracing" tab upon initialization of the PDE-Run configuration (in the dialog "Run configurations..."). Instead, only do them when the tab is first selected. This speeds up opening the dialog "Run configurations..." (and also switching to a PDE-Run configuration when the dialog is already opened). Show a progress indicator when doing some (possibly) long-running operations in the "Tracing" tab. Fixes to eclipse-pde#679
f8d18e2
to
8d12915
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.
Great. So this looks ready from a PDE point of view.
Should we wait until your related Platform PR ist merged, before merging this?
Yes please, let's wait until eclipse-platform/eclipse.platform#766 is merged otherwise this PR will introduce a bug. |
Make sure that the selected tab is activated (i.e. that its "activate" method is called) when switching between existing run configurations in the "Run configurations" dialog. Contributes to eclipse-pde/eclipse.pde#674
Make sure that the selected tab is activated (i.e. that its "activate" method is called) when switching between existing run configurations in the "Run configurations" dialog. Contributes to eclipse-pde/eclipse.pde#674
@HannesWell eclipse-platform/eclipse.platform#766 is merged --> this PR is good to go :) |
Great! |
…acing" tab." This reverts commit 7c1f0ed from eclipse-pde#674. The change introduced a regression causing Tracing tabs not to be initialized properly in specific situation. It requires an update to the Eclipse platform, which will not be integrated into the upcoming release anymore. Therefore, the change is reverted for the release to be reapplied after the next release. The effect of reverting the change will be a loss of the performance improvement in the launch configurations dialog that was gained by the change.
…acing" tab." This reverts commit 7c1f0ed from #674. The change introduced a regression causing Tracing tabs not to be initialized properly in specific situation. It requires an update to the Eclipse platform, which will not be integrated into the upcoming release anymore. Therefore, the change is reverted for the release to be reapplied after the next release. The effect of reverting the change will be a loss of the performance improvement in the launch configurations dialog that was gained by the change.
Make sure that the selected tab is activated (i.e. that its "activate" method is called) when switching between existing run configurations in the "Run configurations" dialog. Contributes to eclipse-pde/eclipse.pde#674
The progress indicator uses
IProgressMonitor.UNKNOWN
as the total amount of work because the (sometimes) long running operation is deep in the call stack: it goes all the way down to theTracingOptionsManager
inorg.eclipse.pde.core
(dependency issues).The operation can not be canceled.
Fixes #679