Community
Participate
Working Groups
Build: I20060815-0800 I have a simple (non-Java) project in my workspace like this: eclipse platform-text 3.3 plan.html When there is an incoming change on plan.html, the synch view looks like this when "All Models" is selected: eclipse 3.3 plan.html I.e., the "platform-text" parent folder is being filtered out. If the "Java Workspace" model is disabled, the problem goes away.
The problem is that the Java label provider is being asked for the label of the folder. For Resource projects, the resource content provider returns all folders as children of the project and provides a label that is the folder path relative to the project. The Resource label provider handles this properly but the Java label provider only shows the folder name. It is my understanding that the CN framework should ask the label provider of the model that provided the content. It does not appear to be doing so in this case. This may be due to the use of pipelining. However, I belive that it still should ask the providing model. Moving to UI/Navigator.
You can reproduce the problem by having a change in a resource project that is at least two folders deep and another change in a Java project. Synchronizing both projects in the same synchronization will reveal the problem.
Michael V -- what is the priority of your extension relative to the Resource extension? If you specify a higher priority, you will be invoked first. The contributing extension is included in the quest to find a valid label, but there are cases where this can be overridden.
Yes, Java has a higher priority than Resources. The project is question is not a Java project so the Java content provider is not adjusting the content at all. I would expect the label provider to follw a similar pattern. That is, either the Resources contribution should provide the label for the content it contributes or there should be a label pipeline just as there is a content pipeline.
The label pipeline works as follows: All visible, enabled extensions are determined (including the source), and sorted by priority. For each label provider ordered by priority, determine the overriding extensions; query all visible, enabled overriding extensions for a valid label/icon repeat If no valid label + icon pairing is found (a non-null value for both the image and the label), the next label provider in the series is queried. This effectively builds a tree of label providers ordered by priority, with overrides also ordered by priority. This algorithm has been successful in use cases I'm aware of (the Compressed Web Project extension is the best example of this in action).
The problem is that the Java model provider doean't know if the resource provider is active or not. Is there a way for the Java label provider to query whether the resource content extension is enabled? If the resource extension is enable, Java can then return null and hence delegate to the resource label provider.
You would have to have a dependency on the resource extension id. You can use the Activation Service (INavigatorContentService.getActivationService()) to check if a particular extension is active. Would that work?
Yes, that would work. Currently, the label provider does not have access to the service. Can you change ICommonContentExtensionSite to provide access to the service?
I can. Is this a requested fix for 3.2.1 or 3.3?
Since it requires API, it can only happen for 3.3.
Created attachment 53749 [details] Screen shot I just wanted to make sure this hasn't fallen off the radar. I regularly have to puzzle through incoming changes in the sync view like the one in the attached screen shot, and with the empty parent folders missing from the view it's really hard to tell what's coming in.
(In reply to comment #10) > Since it requires API, it can only happen for 3.3. We are past the API freeze now.
I have provided a patch to JDT/UI that will fix the folder name issue (see bug 171099). However, this is a very targeted fix. I think we still need what was outlined in the discussion (see comment 8).
Is this still planned for 3.5?
This bug has not shown up in any of my lists because of the bad title, fixing the title.
(In reply to comment #10) > Since it requires API, it can only happen for 3.3. Looks like this one fell through the cracks for quite some time. Removing target milestone since it is too late for 3.5. Francis, feel free to target for 3.6 if you think you can work on this in the next cycle.
I tried this on HEAD on 3.6 and it seems to work OK. In the last couple of years there was a lot of work in label provider overriding and having the label provider associated with the NCE that contributed the object be used; I think this might have addressed this issue. Also, I don't see the Java Model as even an option with the non-Java project, so maybe that's something that fixed the problem. I tried this with an outgoing change, not an incoming change.
Created attachment 161265 [details] What I see now, looks right
Please reopen if there is something I don't understand about this.
I still see this nearly every day. I just confirmed the bug is still there with I20100302-0800. It is quite easy to reproduce, as mentioned in comment #2. An incoming change in a simple project at least two levels deep, combined with any kind of change in a Java project will do the trick.
Created attachment 161302 [details] Screen shot on I20100302
(In reply to comment #20) > combined with any > kind of change in a Java project will do the trick. That's the part I was missing, having a Java change too. Thanks for the clarification.
(In reply to comment #8) > Can you change ICommonContentExtensionSite to provide access to the > service? This has been done. ICommonContentExtensionSite.getService().getActivationService() will get you there. Moving to JDT/UI to make the change to sense the existence of the resource content provider and skip providing the label in that case.
Here are two thread dumps taken while simply moving the mouse away from the Package Explorer into the shell to make the dump: "main" prio=6 tid=0x00519800 nid=0xba8 runnable [0x003dd000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.win32.OS.HeapAlloc(Native Method) at org.eclipse.swt.graphics.TextLayout.shape(TextLayout.java:3221) at org.eclipse.swt.graphics.TextLayout.computeRuns(TextLayout.java:240) at org.eclipse.swt.graphics.TextLayout.getBounds(TextLayout.java:1559) at org.eclipse.jface.viewers.StyledCellLabelProvider.updateTextLayout(StyledCellLabelProvider.java:307) at org.eclipse.jface.viewers.StyledCellLabelProvider.measure(StyledCellLabelProvider.java:285) at org.eclipse.jface.viewers.OwnerDrawLabelProvider$OwnerDrawListener.handleEvent(OwnerDrawLabelProvider.java:56) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1002) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1026) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1011) at org.eclipse.swt.widgets.Tree.sendMeasureItemEvent(Tree.java:4370) at org.eclipse.swt.widgets.Tree.CDDS_ITEMPREPAINT(Tree.java:977) at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:7185) at org.eclipse.swt.widgets.Control.wmNotify(Control.java:4887) at org.eclipse.swt.widgets.Composite.wmNotify(Composite.java:1838) at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:4517) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4006) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4654) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2338) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1530) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4042) at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:5821) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4641) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2435) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3508) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2404) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2368) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2220) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) 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:367) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:611) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:566) at org.eclipse.equinox.launcher.Main.run(Main.java:1363) at org.eclipse.equinox.launcher.Main.main(Main.java:1339) "main" prio=6 tid=0x00519800 nid=0xba8 runnable [0x003dd000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.win32.OS.ScriptTextOut(Native Method) at org.eclipse.swt.graphics.TextLayout.drawRunText(TextLayout.java:982) at org.eclipse.swt.graphics.TextLayout.draw(TextLayout.java:759) at org.eclipse.swt.graphics.TextLayout.draw(TextLayout.java:571) at org.eclipse.swt.graphics.TextLayout.draw(TextLayout.java:548) at org.eclipse.jface.viewers.StyledCellLabelProvider.paint(StyledCellLabelProvider.java:404) at org.eclipse.jface.viewers.OwnerDrawLabelProvider$OwnerDrawListener.handleEvent(OwnerDrawLabelProvider.java:59) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1002) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1026) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1011) at org.eclipse.swt.widgets.Tree.CDDS_ITEMPOSTPAINT(Tree.java:849) at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:7186) at org.eclipse.swt.widgets.Control.wmNotify(Control.java:4887) at org.eclipse.swt.widgets.Composite.wmNotify(Composite.java:1838) at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:4517) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4006) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4654) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2338) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1530) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4042) at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:5821) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4641) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2435) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3508) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2404) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2368) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2220) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) 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:367) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:611) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:566) at org.eclipse.equinox.launcher.Main.run(Main.java:1363) at org.eclipse.equinox.launcher.Main.main(Main.java:1339)
Please ignore the previous comment (wrong bug).
Fixed in HEAD (JavaModelLabelProvider). Available in builds > N20100330-2000. John, please verify in the upcoming N-build.
