Community
Participate
Working Groups
I propose a new API in the JFace Viewer framework that handles the cases where the viewer is empty exactly like is handled by Matthias Becker in bug 543746. This user would use it like this given example: TreeViewer viewer = new TreeViewer(parent, SWT.NONE); viewer.setContentProvider(ArrayContentProvider.instance); viewer.setLabelProvider(MyLabelProvider.instance); viewer.setEmptyHelper(new MyEmptyViewHelper()); MyEmptyViewHelper extends org.eclipse.ui.jface.EmptyViewerHelper The empty viewer helper would show instructional content when the viewer is empty just like is done for some Eclipse views in bug 543746 We see this pattern emerge everywhere without it being addressed properly. See for example an empty git repository view. See the attachment on how IMHO the pattern is implemented correctly and incorrectly.
Created attachment 277496 [details] Occurrences of the empty viewer pattern
+1
+1 can also be used to just show a text as a hint like in org.eclipse.swt.widgets.Text.setMessage(String message). What I want to say is, that it is not always complex things. Sometimes a text is sufficient. Do you think the API should be able to cover this simple case by e.g. a default implementation which just shows a text?
(In reply to Marcus Höpfner from comment #3) > What I want to say is, that it is not always complex things. Sometimes a > text is sufficient. I would even say that in most cases it should be a simple text. Image a new workspace where every view has such *massive* on-boarding content like the project explorer now got. I think this would overwhelm users.
(In reply to Wim Jongman from comment #0) > I propose a new API in the JFace Viewer framework that handles the cases > where the viewer is empty exactly like is handled by Matthias Becker in bug > 543746. And bug 544142.
Please try to address this by 4.11 M3. JDT UI usually does not use internal classes.
(In reply to Matthias Becker from comment #4) > (In reply to Marcus Höpfner from comment #3) > > What I want to say is, that it is not always complex things. Sometimes a > > text is sufficient. > > I would even say that in most cases it should be a simple text. Image a new > workspace where every view has such *massive* on-boarding content like the > project explorer now got. I think this would overwhelm users. OK, I guess I misunderstood the purpose of the new API. I was expecting that it's what we have now as internal class and which must become API, so that JDT and others can legally use it. And I was expecting that the API allows to - add additional links - add a context menu (like the ones we had before in the empty views) This can be done via APIs or extension point. If the latter, it can't live in JFace. If I really misunderstood, then we need a separate bug to turn the internal EmptyWorkspaceHelper into API. And that must have higher priority than this bug here.
Matthias, Dani assigned you. Do you plan to work on this?
(In reply to Wim Jongman from comment #8) > Matthias, Dani assigned you. Do you plan to work on this? Not currently.
(In reply to Matthias Becker from comment #9) > (In reply to Wim Jongman from comment #8) > > Matthias, Dani assigned you. Do you plan to work on this? > > Not currently. At least the current implementation should be made API. The current situation is not OK.
Mass change, please reset target if you still planning to fix this for 4.11.
Update to record progress: The objective is: "Enable showing onboarding instructions for a JFace Viewer (when a JFace Viewer is empty)". The API that I want to add is something like this: StructuredViewer.setOnboardingProvider(OnboardingProvider obp) constructor OnboardingProvider(String message, IAction... actions) I am trying to avoid that the user needs to create a shared composite for the viewer and onboarding instructions. Instead, I want the shared composite to be created by the onboarding logic. However, from a JFace Viewer point of view, the underlying SWT parent structure is not predictable. The possibilities are endless and there are other known complexities like TableColumnLayout which requires the Viewers' control to be the only parent of a Composite. This approach requires too much SWT magic like Layout conversions and reparenting. I will abandon this and try my luck with an overlay composite that does not share any of the parents of the view. All remarks are welcome.
(In reply to Dani Megert from comment #7) > (In reply to Matthias Becker from comment #4) > > (In reply to Marcus Höpfner from comment #3) > > > What I want to say is, that it is not always complex things. Sometimes a > > > text is sufficient. > > > > I would even say that in most cases it should be a simple text. Image a new > > workspace where every view has such *massive* on-boarding content like the > > project explorer now got. I think this would overwhelm users. > OK, I guess I misunderstood the purpose of the new API. I was expecting that > it's what we have now as internal class and which must become API, so that > JDT and others can legally use it. And I was expecting that the API allows to > - add additional links > - add a context menu (like the ones we had before in the empty views) > > This can be done via APIs or extension point. If the latter, it can't live > in JFace. > > If I really misunderstood, then we need a separate bug to turn the internal > EmptyWorkspaceHelper into API. And that must have higher priority than this > bug here. Filed bug 544724.
*** Bug 544724 has been marked as a duplicate of this bug. ***
Mass change, please reset target if you still planning to fix this for 4.12.
