friends of e4.ui...? [message #967095] |
Thu, 01 November 2012 09:39  |
Eclipse User |
|
|
|
Until recently, I was affected by the Eclipse 4 UI only as an end-user (with all the issues discussed elsewhere).
Yesterday I worked on a requirement that sounds like a perfect candidate to get my hands dirty on the new API: a command to open an editor into a specific part stack which is not the editor area.
I was quite surprised to find myself walking in discouraged areas: literally all the new "API" I'm using isn't actually API, all have "x-friends" lists and since I'm not listed as a friend I'm told that I'm not welcomed to use these packages.
Having coined notions like "gradual encapsulation" [1] and even "decapsulation" [2] I'm not utterly scared by using a few classes & methods that I wasn't expected to. But seeing the entire wealth of o.e.e4.ui.workbench and o.e.e4.ui.model.workbench behind fences ("private party - by invitation only") makes me feel I'm walking the wrong alley.
What's the message behind these x-friends declarations?
- these models shouldn't be used programmatically?
- these API are not yet finalized? (schedule?)
- nobody working on this cares about API cleanness, the x-friends are simply forgotton remnants of the days of incubation?
- these parts of the Eclipse SDK are actually still in incubation?
As usual I'm happy the technology allows me to ignore the restrictions, but - as usual - I'm very much interested in learning about the intention behind those fences.
cheers,
Stephan
[1] http://www.jot.fm/issues/issue_2008_12/article3.pdf
[2] http://www.objectteams.org/def/1.3/s3.html#s3.4
|
|
|
|
|
|
|
|
|
Re: friends of e4.ui...? [message #975157 is a reply to message #975051] |
Wed, 07 November 2012 11:49  |
Eclipse User |
|
|
|
Thanks, I guess I'm mostly on safe grounds 
FYI, this is the current snippet that works fine in my tool:
private IEditorPart createMyEditor(IPageSite site, FileEditorInput input) {
EPartService partService = (EPartService) site.getService(EPartService.class);
EModelService modelService = (EModelService) site.getService(EModelService.class);
MApplication parent = getApplication(partService);
// create an empty model:
MPart newEditorPart = partService.createPart(CompatibilityEditor.MODEL_ELEMENT_ID);
// create a new editor:
IWorkbenchWindow activeWbWindow = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
WorkbenchPage workbenchPage = (WorkbenchPage)activeWbWindow.getActivePage();
EditorReference ref = workbenchPage.createEditorReferenceForPart(newEditorPart, input, MyEditor.ID, null);
if (ref == null) return null; // no hope: can't find reference for our editor
// provide constructor arguments for CompatibilityEditor via context (looks FRAGILE to me!!):
IEclipseContext newContext = parent.getContext().createChild();
newEditorPart.setContext(newContext);
newContext.set(EditorReference.class, ref);
newContext.set(MPart.class, newEditorPart);
// this creates the editor:
partService.showPart(newEditorPart, PartState.CREATE);
// show it in the "bottom" stack as defined in the perspectives "Java" and "My Perspective":
MPerspective activePerspective = modelService.getActivePerspective(getWindow(parent));
MUIElement bottomElement = modelService.find("bottom", activePerspective);
if (bottomElement instanceof MPartStack) {
MPartStack bottomStack = (MPartStack) bottomElement;
bottomStack.getChildren().add(newEditorPart);
bottomStack.setSelectedElement(newEditorPart);
}
return (IEditorPart) ((CompatibilityEditor)newEditorPart.getObject()).getEditor();
}
Without @SuppressWarnings("restriction") almost every single line in this method has a warning. At a closer look one of these warnings may actually be relevant even after E4 API have been declared. That's why suppressing the warning may be a bad idea...
cheers,
Stephan
|
|
|
Powered by
FUDForum. Page generated in 0.04404 seconds