| Summary: | [Compatibility] IWorkbenchSiteProgressService.warnOfContentChange not implemented in 4.x | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | John Arthorne <john.arthorne> | ||||||||
| Component: | UI | Assignee: | Daniel Rolka <daniel.rolka> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | curtis.windatt.public, daniel.rolka, daniel_megert, emoffatt, pwebster, remy.suen | ||||||||
| Version: | 4.2 | ||||||||||
| Target Milestone: | 4.3 M7 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows 7 | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Think we should use a tag here and then the CSS would determine how to render this in the tab item? See also bug 372466. Is there any API to turn this off once it's set ? I don't see it, I was expecting a boolean arg or something. Remy is correct in that adding a 'ContentChanged' tag to the MPart and having the CSS control the result would seem to be the way to go. However, these tags are persistent so if we do lack an API to 'clear' the state I'll have to resort to listening for the MPart's widget -> null in order to clear it when the view is closed (sort of hacky). It feels like more of an event than a model state, but I suppose if we want a visible change in the UI it would need to be present in the model. For what it's worth, I believe the 3.x behaviour was that the appearance reverted to normal on the next active part change. (In reply to comment #4) > It feels like more of an event than a model state, but I suppose if we want a > visible change in the UI it would need to be present in the model. For what > it's worth, I believe the 3.x behaviour was that the appearance reverted to > normal on the next active part change. In 3.8 the state is reset if that (bold) part is activated (but not if some other part gets activated). Created attachment 229739 [details]
Change in the css styling
Created attachment 229755 [details] Styling update after pushing the fix for #372466 I have synchronized the patch with the fix for bug 372466. So the current patch is valid The pattern in the patch looks good, consistent with the previous bug. There's one scenario that didn't work quite right. I have a simple java Hello World program that I run. As I re-run it (using CTRL+F11 or ALT+R N and then double click) if the Console view is hidden, it comes to the front but its stack tab stays bold even though the console view is now active. It'll stay active until you activate another view and come back. PW With https://git.eclipse.org/r/#/c/11927/4 (patch set 4) when I run UIAllTest I get errors in TabStateHandlerTest like. Could you check that you're running UIAllTests as a Headless application? java.lang.NullPointerException at org.eclipse.swt.custom.CTabFolder.checkStyle(CTabFolder.java:335) at org.eclipse.swt.custom.CTabFolder.<init>(CTabFolder.java:242) at org.eclipse.e4.ui.workbench.renderers.swt.TabStateHandlerTest.testHandleEventWhenTabBusyEvent(TabStateHandlerTest.java:74) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at junit.framework.TestCase.runTest(TestCase.java:176) at junit.framework.TestCase.runBare(TestCase.java:141) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:129) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:613) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) Created attachment 229859 [details] The fix proposal for the NPE in the TabStateHandlerTest run in the headless mode (In reply to comment #9) > With https://git.eclipse.org/r/#/c/11927/4 (patch set 4) when I run > UIAllTest I get errors in TabStateHandlerTest like. Could you check that > you're running UIAllTests as a Headless application? > > > java.lang.NullPointerException > at org.eclipse.swt.custom.CTabFolder.checkStyle(CTabFolder.java:335) > at org.eclipse.swt.custom.CTabFolder.<init>(CTabFolder.java:242) > at Paul, Could you please verify if the considered fix solves the NPE issue in the headless mode? thanks, Daniel (In reply to comment #10) > Created attachment 229859 [details] > The fix proposal for the NPE in the TabStateHandlerTest run in the headless > mode > > Could you please verify if the considered fix solves the NPE issue in the > headless mode? That solves the problem. Want me to simply include the fix in my review? PW Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ecc24a3208fa0c32e882a8abd82749b0d265708d and http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=ee7a9ef6370dc94444e1f39d5f6b97311cca1adc Thanks Daniel. PW Verified in the build I20130428-2000 |
This method is used to let the user know that the contents of a view have changed. I believe this was previously implemented by setting the tab font to bold. Current 4.x implementation in WorkbenchSiteProgressService: public void warnOfContentChange() { // site.getPane().showHighlight(); } Note there is also bug 282585 for marker views in particular, which is a different problem. In that case the problem is that warnOfContentChange is not called at all.