[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] API and package structure
|
Hi there,
As promised, here's the full list of classes in org.eclipse.e4.** we
explicitly import in our application. I hope that will be useful.
$ grep -R "import org.eclipse.e4" bundles/ | cut -d ':' -f 2 | cut -d
';' -f 1 | sort | uniq
import org.eclipse.e4.core.commands.ECommandService
import org.eclipse.e4.core.commands.EHandlerService
import org.eclipse.e4.core.contexts.ContextFunction
import org.eclipse.e4.core.contexts.ContextInjectionFactory
import org.eclipse.e4.core.contexts.EclipseContextFactory
import org.eclipse.e4.core.contexts.IContextFunction
import org.eclipse.e4.core.contexts.IEclipseContext
import org.eclipse.e4.core.contexts.RunAndTrack
import org.eclipse.e4.core.di.annotations.CanExecute
import org.eclipse.e4.core.di.annotations.Execute
import org.eclipse.e4.core.di.annotations.Optional
import org.eclipse.e4.core.di.IInjector
import org.eclipse.e4.core.di.suppliers.ExtendedObjectSupplier
import org.eclipse.e4.core.di.suppliers.IObjectDescriptor
import org.eclipse.e4.core.di.suppliers.IRequestor
import org.eclipse.e4.core.services.events.IEventBroker
import org.eclipse.e4.ui.di.Focus
import org.eclipse.e4.ui.di.Persist
import org.eclipse.e4.ui.internal.workbench.swt.AbstractPartRenderer
import org.eclipse.e4.ui.internal.workbench.swt.ShellActivationListener
import org.eclipse.e4.ui.model.application.commands.impl.CommandsPackageImpl
import org.eclipse.e4.ui.model.application.commands.MBindings
import org.eclipse.e4.ui.model.application.commands.MBindingTableContainer
import org.eclipse.e4.ui.model.application.commands.MHandler
import org.eclipse.e4.ui.model.application.commands.MHandlerContainer
import
org.eclipse.e4.ui.model.application.descriptor.basic.MPartDescriptorContainer
import org.eclipse.e4.ui.model.application.impl.ApplicationImpl
import org.eclipse.e4.ui.model.application.impl.ApplicationPackageImpl
import org.eclipse.e4.ui.model.application.MApplication
import org.eclipse.e4.ui.model.application.MApplicationElement
import org.eclipse.e4.ui.model.application.ui.advanced.MPerspective
import org.eclipse.e4.ui.model.application.ui.advanced.MPerspectiveStack
import org.eclipse.e4.ui.model.application.ui.advanced.MPlaceholder
import org.eclipse.e4.ui.model.application.ui.basic.impl.BasicFactoryImpl
import org.eclipse.e4.ui.model.application.ui.basic.MBasicFactory
import org.eclipse.e4.ui.model.application.ui.basic.MInputPart
import org.eclipse.e4.ui.model.application.ui.basic.MPart
import org.eclipse.e4.ui.model.application.ui.basic.MPartSashContainer
import
org.eclipse.e4.ui.model.application.ui.basic.MPartSashContainerElement
import org.eclipse.e4.ui.model.application.ui.basic.MPartStack
import org.eclipse.e4.ui.model.application.ui.basic.MStackElement
import org.eclipse.e4.ui.model.application.ui.basic.MTrimBar
import org.eclipse.e4.ui.model.application.ui.basic.MTrimmedWindow
import org.eclipse.e4.ui.model.application.ui.basic.MWindow
import org.eclipse.e4.ui.model.application.ui.impl.UILabelImpl
import org.eclipse.e4.ui.model.application.ui.impl.UiPackageImpl
import org.eclipse.e4.ui.model.application.ui.MContext
import org.eclipse.e4.ui.model.application.ui.MDirtyable
import org.eclipse.e4.ui.model.application.ui.MElementContainer
import org.eclipse.e4.ui.model.application.ui.menu.impl.MenuFactoryImpl
import org.eclipse.e4.ui.model.application.ui.menu.MMenuContributions
import org.eclipse.e4.ui.model.application.ui.menu.MMenuElement
import org.eclipse.e4.ui.model.application.ui.menu.MToolBarContributions
import org.eclipse.e4.ui.model.application.ui.menu.MToolControl
import org.eclipse.e4.ui.model.application.ui.menu.MTrimContributions
import org.eclipse.e4.ui.model.application.ui.MInput
import org.eclipse.e4.ui.model.application.ui.MUIElement
import org.eclipse.e4.ui.model.application.ui.MUILabel
import org.eclipse.e4.ui.model.application.ui.SideValue
import org.eclipse.e4.ui.services.IServiceConstants
import org.eclipse.e4.ui.widgets.CTabFolder
import org.eclipse.e4.ui.widgets.CTabFolder2Adapter
import org.eclipse.e4.ui.widgets.CTabFolderEvent
import org.eclipse.e4.ui.widgets.CTabItem
import org.eclipse.e4.ui.workbench.IPresentationEngine
import org.eclipse.e4.ui.workbench.modeling.EModelService
import org.eclipse.e4.ui.workbench.modeling.EPartService
import org.eclipse.e4.ui.workbench.modeling.EPartService.PartState
import org.eclipse.e4.ui.workbench.modeling.ESelectionService
import org.eclipse.e4.ui.workbench.modeling.IPartListener
import org.eclipse.e4.ui.workbench.modeling.ISaveHandler
import org.eclipse.e4.ui.workbench.modeling.IWindowCloseHandler
import org.eclipse.e4.ui.workbench.renderers.swt.TrimmedPartLayout
import org.eclipse.e4.ui.workbench.UIEvents
import org.eclipse.e4.ui.workbench.UIEvents.EventTags
The e4.ui.internal imports are done by the drag and drop/minmax/clean
addons that we imported with our code (and appropriately changed to
match the name of our model workbench objects).
Hope this helps :)
--
Simon
Eric Moffatt wrote:
Hi Simon, thanks for the input...I'll see if I can answer some of your
questions below (might help with other's responses as well..;-).
1) Having an e4 BOF at EclipseCon is an excellent idea !! I'll see
what's entailed in setting one up, stay tuned...
2) As far as provisional vs 'real' API goes this note was to get
responses on the 'real' API but most certainly input as to whether we
want to 'lock in' to a particular context value or have it be
provisional are valid. In order to keep the API as simple as possible we
should only be making those things that we are *sure* we need to do
valid RCP apps should be marked API (i.e. feedback requesting that a
particular element be *removed* from the API list is even better than
that which adds more...;-).
3) Only once we have the definitive list of what's 'in', what's 'out'
and what's 'provisional' can we begin to determine how to expose it;
including defining the appropriate package structure(s) as well as
settling on naming conventions (i.e. the what to do with the
"E"nterfaces.like 'EModelService...;-).
Eric
From: Simon Chemouil <eclipse@xxxxxxxxxxxxxx>
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date: 02/11/2011 02:48 PM
Subject: Re: [e4-dev] API and package structure
Sent by: e4-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------
Eric Moffatt racontait le 11/02/2011 20:22:
[snip]
> *_Lazy Consensus Warning:_**Input will be accepted to modify this list
> until March 1st, then this /_is_ / the API that we present at
EclipseCon.*
>
> *NOTE:* Most of you have more experience using the base E4 API's than I
> do so please go over this list thoroughly to ensure that it includes at
> least those elements that you have need in your RCP development... Once
> we determine what's 'in' we can then decide on how to best expose the
> api (and where to put the internals).
[snip]
Hi there,
I've been wanting to reply to this thread for some time but I have my
hands more than full... And this message is not really my reply :).
I'll double check the API you propose and get back soon.
My current understanding is that we're keeping a lot of the API
*provisional*. That's what I interpret from John's "This does not have
to be an "all or nothing" effort. I.e., we don't need to end up in 4.1
with no provisional API" and the lack of discussion about "The other
approach would be to maintain a strong separate between 3.x and 4.x
package names, by calling all 4.x packages something like
org.eclipse.platform.*." (by the way, yes, please, a different
namespace!). So do we agree that this list does not mean "provisional"
API, just "EclipseCon API" (which is nice to get right, but not the same
deal)?
Regarding API usage, our RCP app is using the "July" release. We did not
upgrade the target mostly because we got it working and because there's
only so much purely technical stuff we can do with our client's money
(we're focussed on the functional/business side of the app...).
Switching to a more recent E4 build could trigger a lot of unexpected
surprises so we can't afford it right now. However, I'd like to do what
Brian did for his application and report all the e4 API stuff we're
using. I will do it next week because I have set some free time to
prepare the EclipseCon.
I was also thinking that it would be nice to meet different E4
contributors and discuss the API and general architecture, the good and
the less good :). Mostly about the platform ("E4 Application Platform"),
there are still some open points imo. Is anyone else interested? This
will be my first EclipseCon, so I don't know the ins and outs of
organizing this, but how about an E4 platform BoF?
Regards,
Simon
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
------------------------------------------------------------------------
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
