Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » friends of e4.ui...?
friends of e4.ui...? [message #967095] Thu, 01 November 2012 13:39 Go to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
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 #967333 is a reply to message #967095] Thu, 01 November 2012 17:38 Go to previous messageGo to next message
Lars Vogel is currently offline Lars VogelFriend
Messages: 1098
Registered: July 2009
Senior Member

Hi Stephan,

the Eclipse 4 API has not been released, this was due to capacity restrictions in the team.

See Eclipse 4 Provisional API and For whom is this release.

Best regards, Lars
Re: friends of e4.ui...? [message #967413 is a reply to message #967333] Thu, 01 November 2012 18:50 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Thanks, Lars, for the pointers.

This explains, but still leaves me with an uneasy feeling.

One thing is the funny message "there won't be a 3.9" but "you cannot rely on API for 4.3". Please take this with a grain of salt, but what exactly are we all to think about the maturity of Eclipse 4?

More pragmatically: doesn't the current state teach us all: It's OK to put @SuppressWarnings("restriction") on all our UI classes? We no longer see the relevant warnings because the warning is rendered useless in the current situation.
Any reason against removing the restrictions for current milestones? I'd see double advantage in doing so:
- consumers of these to-be API can re-enable this warning and get the feedback they need when venturing into purely internal packages
- owners of these to-be API experience the necessary pressure to finalize API until M6.

Or is shipping the one and only 4.3 without these API a realistic option?

thanks,
Stephan

PS: I think the single occurrence of "provisional" in the Eclipse wiki is not visible enough. Note also that "x-friends" doesn't communicate whether a package is provisional API or why the restriction exists.
How about a section: "Status" that clearly states which API are considered provisional API, which are considered for release and what's the schedule?
As much as I'd like to contribute for clarification, I'm afraid this information has to come from the team itself.
Re: friends of e4.ui...? [message #967452 is a reply to message #967413] Thu, 01 November 2012 19:25 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
There was a discussion todays e4 meeting on what we make API in Kepler!

The reason we used x-friends is that normally we'd have to use the
provisional package and which would have meant that we'll break anybody
on the world when making API although we are 99% confident that the API
is good!

Tom

Am 01.11.12 19:50, schrieb Stephan Herrmann:
> Thanks, Lars, for the pointers.
>
> This explains, but still leaves me with an uneasy feeling.
>
> One thing is the funny message "there won't be a 3.9" but "you cannot
> rely on API for 4.3". Please take this with a grain of salt, but what
> exactly are we all to think about the maturity of Eclipse 4?
>
> More pragmatically: doesn't the current state teach us all: It's OK to
> put @SuppressWarnings("restriction") on all our UI classes? We no longer
> see the relevant warnings because the warning is rendered useless in the
> current situation. Any reason against removing the restrictions for
> current milestones? I'd see double advantage in doing so:
> - consumers of these to-be API can re-enable this warning and get the
> feedback they need when venturing into purely internal packages
> - owners of these to-be API experience the necessary pressure to
> finalize API until M6.
>
> Or is shipping the one and only 4.3 without these API a realistic option?
>
> thanks,
> Stephan
>
> PS: I think the single occurrence of "provisional" in the Eclipse wiki
> is not visible enough. Note also that "x-friends" doesn't communicate
> whether a package is provisional API or why the restriction exists. How
> about a section: "Status" that clearly states which API are considered
> provisional API, which are considered for release and what's the schedule?
> As much as I'd like to contribute for clarification, I'm afraid this
> information has to come from the team itself.
Re: friends of e4.ui...? [message #967505 is a reply to message #967452] Thu, 01 November 2012 20:25 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Thomas Schindl wrote on Thu, 01 November 2012 20:25
There was a discussion todays e4 meeting on what we make API in Kepler!


Sounds good! Smile
Which space should one watch for progress?

Quote:

The reason we used x-friends is that normally we'd have to use the
provisional package and which would have meant that we'll break anybody
on the world when making API although we are 99% confident that the API
is good!


I agree that x-friends is "better" than using a different package name at this stage.
Also 99% sounds promising ...

cheers,
Stephan
Re: friends of e4.ui...? [message #967558 is a reply to message #967505] Thu, 01 November 2012 21:22 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Best is to ask at e4-dev about - i was not on the call today - only read
the meeting notes.

Anyways, I'd say the model + DI stuff + core services like EPartService
and EModelService won't change. Other stuff like the e.g. the logger are
subject to maybe change in future.

Tom

Am 01.11.12 21:25, schrieb Stephan Herrmann:
> Thomas Schindl wrote on Thu, 01 November 2012 20:25
>> There was a discussion todays e4 meeting on what we make API in Kepler!
>
>
> Sounds good! :)
> Which space should one watch for progress?
>
> Quote:
>> The reason we used x-friends is that normally we'd have to use the
>> provisional package and which would have meant that we'll break anybody
>> on the world when making API although we are 99% confident that the API
>> is good!
>
>
> I agree that x-friends is "better" than using a different package name
> at this stage.
> Also 99% sounds promising ...
> cheers,
> Stephan
Re: friends of e4.ui...? [message #975051 is a reply to message #967095] Wed, 07 November 2012 14:57 Go to previous messageGo to next message
Eric Moffatt is currently offline Eric MoffattFriend
Messages: 118
Registered: July 2009
Senior Member

Tom's analysis is correct. Feel free to use the UI Model, EModelService and EPartService (at least) as API. We simply haven't had the time to write the docs, examples...needed to formally release them.

Stephan, you should be able to implement the new capability by finding the stack you want to use through the EModelService and adding the MPart to it, let me know how it goes !
Re: friends of e4.ui...? [message #975157 is a reply to message #975051] Wed, 07 November 2012 16:49 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Thanks, I guess I'm mostly on safe grounds Smile

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
Previous Topic:Open file from command line
Next Topic:Apply Settings of Application Model
Goto Forum:
  


Current Time: Fri Mar 29 02:25:07 GMT 2024

Powered by FUDForum. Page generated in 0.03337 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top