Community
Participate
Working Groups
There's recently been a flurry of discourse on the e4-dev mailing list (see "More Model Question and Proposals"). This defect is to capture the discussions as well as documenting the actions taken as a result. Tom Schindl has identified a number of deficiencies as part of his work on the UI Model Editor. Details coming...
Proposal 0 - MPerspective: -------------------------- - Remove MPSCElement as super type Proposal 1 - MContribution: --------------------------- - Rename #uri to #contributionUri Proposal 2 - MWindowTrim: ------------------------- - Remove supertype MPSCElement - Add new #trims: List<MWindowTrim> to MWindow Proposal 3 - MWindow: --------------------- - Remove supertype MPSCElement - Add new #detachedWindows: List<MWindow> to MPerspective Proposal 4 - MWindowElement: ---------------------------- - Create new type which has MUIElement as supertype - Replace MPSCElement through MWindowElement in MPerspectiveStack - Add MWindowElement to MPart, MPartSashContainer, MPartStack Proposal 5 - MMenuItem: ----------- - Replace supertype MMenu with MElementContainer<Menu>
Remove V___ and probably replace with sub-packages (though external tools probably having problems with it)
Proposal 5 - MMenuItem (Take 2): -------------------------------- - NEW: MMenuElement extend MItem - MMenu extend MElementContainer<MMenuElement> - MMenuItem extends MMenuElement & MElementContainer<MMenuElement> or better named MSubMenuItem - MHandledMenuItem extends MMenuElement - MDirectMenuItem extends MMenuElement
please also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=305609
We should change the model to support mnemonics (see bug 293360).
We need a new model element type to allow for simple trim controls (MControl?). This is a contribution but *not* a part, specifically it has no Context (i.e. the HeapStatus can't be 'activated').
There's also been discussion about merging 'tags' and 'persistedData' into a single String-to-String map (see bug 304116) which would be called 'persistedData'. Do we want to do this ? I'm +1 for sure.
Re: comment 7: My $0.02: I'd prefer that persistedState be completely at the disposition of the app and treated as an opaque value by the platform and frameworks. That avoids any possibility of key conflicts, or requiring magically-named keys. If it seems like CSS styling will be universal across the widgeting technologies supported by e4 (is it?), then I'd suggest that we reflect that type of terminology in the model. We have @id already, and @class would make sense then too.
Perhaps I could add something else to the mix. Has there been any discussion about having a single App.e4xmi support multiple widgeting technologies? Could we (should we?) extend the UI model to allow accomodating multiple widgeting technologies? The part implementations specified by MPart#URI are generally specific to one technology (e.g., SWT or XWT). Consider modifying e4photo to use both SWT (rich client) and XWT (web-deployment), or SWT and GWT. Perhaps it doesn't make so much sense for the UI. It could make more sense for sharing the commands/handlers though. I suppose those could be brought in by a component.
(In reply to comment #9) > Perhaps I could add something else to the mix. > > Has there been any discussion about having a single App.e4xmi support multiple > widgeting technologies? Could we (should we?) extend the UI model to allow > accomodating multiple widgeting technologies? The part implementations > specified by MPart#URI are generally specific to one technology (e.g., SWT or > XWT). Consider modifying e4photo to use both SWT (rich client) and XWT > (web-deployment), or SWT and GWT. The renering of the Model is completely seperated in the Renderer-Framework what we are defining in the Workbench-Model (though naturally we have added some UI-Concepts) is Widget and Platform neutral. There's a very very tiny interface between the model the rendering call IPresentationEngine and replaceing this with your own makes you model rendered as ASCII, Swing, Qt, Proxied-GWT, ... .
(In reply to comment #8) > Re: comment 7: > > My $0.02: I'd prefer that persistedState be completely at the disposition of > the app and treated as an opaque value by the platform and frameworks. That > avoids any possibility of key conflicts, or requiring magically-named keys. > I'm all with you. PersistedState is something the Contribution is controling and something the framework doesn't touch at all (it should not care at all about it). It simply allows the contributor to restore informations not more not less. So a clear -1 from me on this merge!
(In reply to comment #10) > The renering of the Model is completely seperated in the Renderer-Framework what > we are defining in the Workbench-Model (though naturally we have added some > UI-Concepts) is Widget and Platform neutral. But the class defined in the URI is usually specific to some renderer/technology. For example, the classes implementing the e4photo app (e.g., Preview, Library, Thumbnails) are all specific to SWT. Simply replacing the rendering engine isn't sufficient, unfortunately. Unless the rendering engine can slip in something that is SWT-compatible of course.
(In reply to comment #12) > (In reply to comment #10) > > The renering of the Model is completely seperated in the Renderer-Framework what > > we are defining in the Workbench-Model (though naturally we have added some > > UI-Concepts) is Widget and Platform neutral. > > But the class defined in the URI is usually specific to some > renderer/technology. For example, the classes implementing the e4photo app > (e.g., Preview, Library, Thumbnails) are all specific to SWT. > > Simply replacing the rendering engine isn't sufficient, unfortunately. Unless > the rendering engine can slip in something that is SWT-compatible of course. Well yes and know. You'd have to use a UI-Technology in the Contribution class which can deal with this. One of this options is UFaceKit who would allow you to switch from SWT to Qt to Swing to GWT leaving your UI-Code unaffected. An UFaceKit contribution class would look like this: public class MyView { @Inject public MyView(UIComposite parent) UIFactory f = parent.getFactory(); f.newButton(); // .... } } The UIComposite creation is done by contributing an IContextFunction or by contributing a special PartRenderer which creates it (see here for an example I wrote for Eclipse Summit Europe). Please also note that I gave UFaceKit all features needed to write the complete workbench rendering in it and then no adaption, ... has to take place. Another option would be to write the contribution in a way that it has multiple different constructors and recode your UI in all technologies the Injection-Framework then will choose the correct one based upon the informations available through the rendering engine. This would look something like this (if you have Swing, SWT and Qt): public class MyView { @Inject public MyView(JPanel parent) { // Running in a Swing-Renderer JButton b = new JButton(); parent.add(b); } @Inject public MyView(Composite parent) { // Running in a SWT-Renderer Button b = new Button(parent,SWT.PUSH); } @Inject public MyView(QWidget parent) { // Running in a Qt-Renderer QPushButton b = new QPushButton(parent); } } To sum up - from a framework PoV the control ends at Contribution-Class and there it's up to the implementor to choose the right technology to run in different rendering technologies. As far as I know there's only UFaceKit at the moment which would make write once run in multiple but there are probably others as well. [1]https://dev.eclipse.org/svnroot/eclipse/org.eclipse.ufacekit/bundles/incubation/org.eclipse.ufacekit.incubation/org.eclipse.ufacekit.e4/org.eclipse.ufacekit.ui.core.e4.renderer/src/org/eclipse/ufacekit/ui/core/e4/renderer/spi/UFKContributedPart.java
(In reply to comment #9) > Perhaps I could add something else to the mix. > > Has there been any discussion about having a single App.e4xmi support multiple > widgeting technologies? Could we (should we?) extend the UI model to allow > accomodating multiple widgeting technologies? The part implementations > specified by MPart#URI are generally specific to one technology (e.g., SWT or > XWT). Consider modifying e4photo to use both SWT (rich client) and XWT > (web-deployment), or SWT and GWT. > Hm, so you are asking for having multiple contribution-uris something like Contribution { contributionUris: List<ContributionUri> } ContributionUri { uri: String filter: String } and passed upon the if the filter matches the framework chooses the correct contribution?
Proposal 6 - MCommandParameter & MParameter: -------------------------------------------- If not completely mistaken the MCommandParameter defines the parameters a command accepts and MParameter is the thing to pass stuff to the command. I guess the mapping is done using CommandParameter#name and Parameter#tag. I think we should rename Parameter#tag to Parameter#name. Paul is my assumption correct? Proposal 7 - MBindingContainer: ------------------------------- Rename it to MKeyBindingContainer to be more consitent with e.g. HandlerContainer.
(In reply to comment #15) > Proposal 6 - MCommandParameter & MParameter: > -------------------------------------------- > If not completely mistaken the MCommandParameter defines the parameters a > command accepts and MParameter is the thing to pass stuff to the command. I > guess the mapping is done using CommandParameter#name and Parameter#tag. I > think we should rename Parameter#tag to Parameter#name. Paul is my assumption > correct? I think so. I believe we co-opted Parameter from the original model and now no one uses it but us. > Proposal 7 - MBindingContainer: > ------------------------------- > Rename it to MKeyBindingContainer to be more consitent with e.g. > HandlerContainer. I'm looking at change the binding mechanism, but I'll make sure things are consistent when I change the model. PW
Proposal 8 - ModelComponent: ---------------------------- Currently it defines the handlers itself but it would make more sense to inherit from HandlerContainer. Beside that it should inherit from BindingContainer as well.
(In reply to comment #17) > Proposal 8 - ModelComponent: > ---------------------------- > Currently it defines the handlers itself but it would make more sense to > inherit from HandlerContainer. Beside that it should inherit from > BindingContainer as well. I've created an extra bug for this. This is a API compatible change and I'd like to release it ASAP. The testsuite and all demo apps are still working with this change.
If there are any other changes that are need for EclipseCon please follow Tom's example and split them off into a separate defect and make this defect depend on it (as he did with bug 304794). This way we have a better chance of keeping track of what's already been done...thanks. I may need to be making some changes, specifically adding a life-cycle hint controlling what happens when a container becomes empty, something along these lines: onEmpty - an enumeration with the following values: "Remove" (causes the container to be removed from the model, default behavior) "Hide" (causes the container to be removed from the visible presentation but left in the model (what we do with View Stacks) "Leave" (causes the empty container to remain in the visible presentation, what we do for the last empty editor stack). Are there any others I should consider?
bug 305793 - move keybindings into a small number of flat tables. Use BindingContext hierarchy to weight them. PW
(In reply to comment #13 and comment #14) UFaceKit looks nifty, and is definitely a workable solution for new code. The all-in-one class with injection approach causes the number of plugins to balloon. It's probably not workable in the long term. The approach you've described in comment #14 is more the approach I was thinking of. But it also becomes messy, doesn't it. Perhaps the alternative, of simply copying and modifying the App.e4xmi for each, is less of a bother.
(In reply to comment #21) > (In reply to comment #13 and comment #14) > > UFaceKit looks nifty, and is definitely a workable solution for new code. > right :-) > The all-in-one class with injection approach causes the number of plugins to > balloon. It's probably not workable in the long term. > I think the problem is that you have write your UI twice and that's not making a whole lot of sense. > The approach you've described in comment #14 is more the approach I was > thinking of. But it also becomes messy, doesn't it. > I guess so too. I think the core model should not hold it but one could extend the .ecore for his/her own application if this is a requirement. > Perhaps the alternative, of simply copying and modifying the App.e4xmi for > each, is less of a bother. think so too.
Should we swap EList out for List? Doesn't look like EMap can be swapped out for Map though.
Note that EMap has a modifiable map() view.
Proposal 9 - TestHarness: ------------------------- Remove from UIElement.ecore and move it to it's own .ecore in the test suite because it a pure test element.
Change redux: Here are all the changes that are on the table at the moment. If it's not here and you think it should be post back. If you want to comment for or against any of the suggestions then great (please try to give scenarios as to why though :). These have been paraphrased from the original proposals...if I've gotten one wrong let me know. 0) turn the 'V___' classes into packages. Move the TestHarness package under the 'tests' CVS tree. 1) change 'uri' in MContribution to 'contributionURI' 2) change 'BindingContainer' to 'KeyBindingContainer' 3) only allow MWindowTrim directly under MWindow 4) only allow MPerspectiveStacks directly under MWindow 5) only allow MWindow directly under either MWindow or MPerspective 6) Replace 'tags' with a String-to-String map called 'persistedState' and remove the current 'persistedState' attribute from MContibution 7) Menu changes, see comment #3 8) Support mnemonics for MMenuItems separate from the label 9) drop EList in favor of list (and EMap in favor of Map?)
Dang, missed my own! :) 10) Create a new element MControl and allow the trim to contain both MToolbar and MControl. This is to support non-TB trim like the HeapStatus.
I've just checked in a first take on adding subpackages into the model_tweaking_round3 branch
One more: Ensure that the 'Descriptor' elements are *not* MUIElements (the same way an ImageDescriptor is not an Image but can produce one).
Created attachment 164140 [details] A first attempt on structuring
I suggest to rename "PSCElement" in the model (Remy just reminded me in the IRC that it stands for MPartSashContainerElement). I believe the rest of the model elements are pretty self-explaining which is helpful and it would be nice to see this also for PSCElement. For example the new name could be: PartContainerElement or PartSashContainerElement It is longer but it is more descriptive.
Marcelo, you and Dave had an URI proposal/problem @ EclipseCon2010. Would like to raise your voice here? It could probably have an impact to this model tweaking round.
Just a random thought which might help with the techmix problem Brian came up in comment 9 (in future without breaking something). Should we probably model Contribtion#URI? URI { } SingleURI { URI: String } Another thing about uris is that I think we should somehow encode the type (JavaClass, JavaScript-File) we are pointing to in the path. 3 possibilities: a) Encode it into the protocol: bundle-java:/my.plugin.id/my.package.MyClass bundle-javascript:/my.plugin.id/my/package/MyClass.js bundle-groovy:/my.plugin.id/my/package/MyClass.groovy ... * When modeling the URI b) Special Subclasses (JavaURI, JavaScriptURI, ...) c) Add an interpreter type-id attribute to SingleURI => a)
(In reply to comment #33) > Just a random thought which might help with the techmix problem Brian came up > in comment 9 (in future without breaking something). > > Should we probably model Contribtion#URI? > > URI { > } > > SingleURI { > URI: String > } > After having written this I think that Contribution should be a much more flexible concept than simply using URIs (though in our initial version will use URIs people can extend it and use whatever they want to contribute). So I'd propose we change the Contribution-Class like this: ----------8<---------- Contribution { contributionDefinition: ContributionDefinition } abstract ContributionDefinition { } ----------8<---------- The we can decide on if we want: ----------8<---------- ContributionDefinitionURI extends ContributionDefinition { uri: String } ----------8<---------- or ----------8<---------- JavaClassContributionDefinition extend ContributionDefinition { bundle: String class: String } ----------8<---------- No matter how we decide modeling the ContributionDefinition as a real Class and not as a simple String would give us much more power and flexibility.
(In reply to comment #32) The URI discussion is happening here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=307458. The last idea was to go for a new URI schema. PaulW suggested "bundleclasspath", which I like. So the URI of a class to be used by a handler would be: bundleclass://<bundle id>/<fully qualified name of the class>
On: -----------8<----------- 6) Replace 'tags' with a String-to-String map called 'persistedState' and remove the current 'persistedState' attribute from MContibution -----------8<----------- comment 8 & comment 10 vote this proposal. I for now changed tags to a String-to-String map but the both stores have their purpose and we should not mix them into one location
[1:47p] briandealwis: tomschindl, emoffatt: how 'bout differentiating id from xmi:id? I was just bit by this again the other day... [1:47p] tomschindl: rename to elementId? [1:48p] tomschindl: or appElementId? [1:48p] briandealwis: elementId is good, I think
Time to summerize the current Branch-State: * comment 26: 0) done beside the new .ecore for tests 1) done still room for discussing proposal in comment 34 2) done but adjusted naming BindingTableContainer 3) done 4) done (discussion with Eric about this still open) 5) done (discussion with Eric about this still open) 6) done but like proposed in comment 36 7) done 8) done 9) done in the genmodel * comment 27: 10) open Eric? I'm not an expert on this and what you have in mind * comment 29: 11) done * comment 31: 12) done * comment 37: 13) done This leaves us with ------------------- * To discuss items 4-5 * To implement 10 * To discuss: Contribition proposal in comment 36
Re: c#10 and c#27: Some discussion with Eric on #eclipse-e4: We need a Control that inherits from UIElement and Contribution. This would allow embedding a search box (e.g., bug 304440) into trim. But it would also be nice to allow Controls to be embedded in ToolBars too: it would be equally good to embed a search box in a view's toolbar. Perhaps a ToolControl that inherits from ToolItem and Control?
Some more input on the Window/Perspective and Window as child discussion from comment 38: Eric mentionned on IRC that he's not comfortable that the Windows are not getting ElementContainer#children. His argument was the they are children of the Shell (has it as their parent) and this requires us to make special code for Tree-Traversal. I've now taken a look at SWT and well guess what they do it like I proposed to do it. If you look at Shell you have 2 distinct lists: * Shell#getChildren() == Window#children * Shell#getShells() == Window#windows Another probably more subtle problem with children and mixing in Window into this list is (the reason why I move trims to their own Window#trims) is that if you mix them like this: W-P1-W-P2 which leads to a window which looks like this (assuming we are using FillLayout): -------------------- | P1 | | | -------------------- | P2 | | | -------------------- If an Model-User now moves P2 one index up it would expect the UI look like this: -------------------- | P2 | | | -------------------- | P1 | | | -------------------- but in reality this won't happen because the internal list would be W-P1-P2-W. So IMHO what we have in ElementContainer#children is the thing we render in the MAIN-Panel of a UI (and WindowTrim/Window don't get rendered there). So now to the argument of Eric that we don't have a nice Tree-Structure anymore and need to add special cases for Window/Trim. There are 2 possibilities to address it: a) We add a virtual attribute to ElementContainer (named computedChildren) which is volatile, transient which maps in Windows and Trim in the list b) We simply use eContents()/eAllContents() please refer to the JavaDoc to understand the difference for traversal Summary from my side. I think modeling Trim/Window as extra attributes in the model is the way to go because: a) I don't see a problem traversing stuff b) SWT does it the same (and probably other UI-Technologies also)
Just for all people who'd like to align their code to the new structure. The .ecore found currently in the branch is probably going to 95% away from what is going to the final structure of our model. We've yesterday also regenerated the code for the domain model and so you can start aligning your bundles to it. Beside the restructuring of the model there are some remarkable difference because we are now completely hiding EMF which means the that there is no MApplicationPackage, MMenuPackage, ... anymore. If you need access to the EMF-Metadata like EClasses, EStructuralFeatures, ... you need to use the Impl-Class (ApplicationPackageImpl, MenuPackageImpl,...).
Personally, I think suppressing the metadata interface is a bad idea. You're effectively forcing anyone who writes code that will deal with notifications to paw through the XyzPackageImpl class to get it...
(In reply to comment #42) > Personally, I think suppressing the metadata interface is a bad idea. You're > effectively forcing anyone who writes code that will deal with notifications to > paw through the XyzPackageImpl class to get it... Though I completely agree with you. I think users will not attach listeners to the model elements, only the internals do and some SPI implementors (e.g. people writing a Renderer). As far as I remember the consenus was to hide EMF from our API and that's what I've done now :-)
Eric, I've just checked in a restructured version of the menu stuff. It now works similar to how MenuManager/Action are working in JFace There are follow different type of elements involved: * MenuElement extends UIElement, UILabel * Item extends UIElement, UILabel (adds some extra stuff like selected, ...) * MenuItem extends Item, MenuElement => Represents a leave in the Menu-Tree and is used to create a Separator or should we probably model a Separator as an extra type because all of the attributes it is inheriting from Item, and UILabel don't make any sense to it - my proposal would be to model it as an extra type and remove the ItemType.SEPARATOR * Menu extends ElementElement, ElementContainer<MenuElement> => Represents the container to build a (Sub)Menu-tree * DirectMenuItem extends MenuItem, Contribution * HandledMenuItem extends MenuItem, HandledItem Maybe you can take a look and tell me what you think about it?
I've gone a head and implemented by Separator-Proposal - if we don't like all is done through a single commit so we can revert it easily.
Ok. We just found something we need to fix before we can lock down the model: It's the problem of String-References vs. ModelInstance-References. Let's take as an easy and understandable example how KeyBinding. Currently it is defined as: KeyBinding { command: Command } The above is a problem when we want to contribute a KeyBinding to a Command to an already existing Command-Instance (defined else where). We can solve this using String-References like we do in 3.x which has the drawback that also people who could use Model-References need to use Strings which leads to subtle problems with typos, ... . Another probably better solution is to make a hybrid solution: 1) We define a basic Reference<R>-Interface interface Reference<R> { reference: R (volatile,transient) } 2) Let command implement this newly defined interface class Command extends Reference<Command> { public Command getReference() { return this; } } 3) Modify KeyBinding to KeyBinding { commandReference: Reference<Command> } For people who have access to a Command-Instance the process of connecting them is the same it has been before. -------------------------------------- For contributors who can't directly reference the Command we'd define: -------------------------------------- 4) Define a new IdReference IdReference<R> extends Reference<R> { public R getReference() { // Search with the ID in the resource } } 5) Define a CommandIdReference CommandIdReference extends IdReference<Command> { } The only change in our source code is that whenever we simply called getCommand() we'd now call getCommandReference().getReference().
In reply to comment #40... You got most of my take right except for two things: 1) Now *all* windows expose the 'trim' ability, something we had taken great pains not to do. Boris, many of these objections came from you, any comment? 2) The example you give does not reflect how the e4 windows are currently being used. Currently we only ever have *one* element as a child of an MWindow (either an MPSCElement, MPartStack or MPart), never more than one. Also, clients don't see the model, they see the results of its being rendered; the order/containment of the elements is not relevant to them. For example in your scenario clients would never move a part 'one index up', they'd drag P2 above P1. If they're looking at it through our tooling then that tool should separate out the two different types. I just think we're under-utilizing an otherwise proven mechanism (tree/recursion), eroding the ability to write tight, non-special-case code against the model. Now everybody else that wants to do analysis of the model...has to 'know' where all the bits are and even the internal code becomes more complex. Is this a good idea given that the clients never see the model? I'm sure that the model editor can make this work without losing the advantages...;-).
(In reply to comment #47) > In reply to comment #40... > > You got most of my take right except for two things: > > 1) Now *all* windows expose the 'trim' ability, something we had taken great > pains not to do. Boris, many of these objections came from you, any comment? > The model we started of also had this possibility there's no change beside storing them in an extra attribute. > 2) The example you give does not reflect how the e4 windows are currently being > used. Currently we only ever have *one* element as a child of an MWindow > (either an MPSCElement, MPartStack or MPart), never more than one. Also, > clients don't see the model, they see the results of its being rendered; the > order/containment of the elements is not relevant to them. For example in your > scenario clients would never move a part 'one index up', they'd drag P2 above > P1. If they're looking at it through our tooling then that tool should separate > out the two different types. > Sorry if you have one than its a single attribute named contentPane! How would you prevent people from adding multiple MPartStack, ... . > I just think we're under-utilizing an otherwise proven mechanism > (tree/recursion), eroding the ability to write tight, non-special-case code > against the model. Now everybody else that wants to do analysis of the > model...has to 'know' where all the bits are and even the internal code becomes > more complex. Is this a good idea given that the clients never see the model? > > I'm sure that the model editor can make this work without losing the > advantages...;-). SWT (A Child-Shell is not part of Shell#getChildren()) sees to world like I do so it could not be that wrong. Why can't you simply use eAllContents() for your traversal and you once more have your tree-recursion?
(In reply to comment #48) > > Sorry if you have one than its a single attribute named contentPane! How would > you prevent people from adding multiple MPartStack, ... . > I'm just pointing out that this *is* what all of our models look like...but the model allows it so I'll drop this argument :) > > SWT (A Child-Shell is not part of Shell#getChildren()) sees to world like I do > so it could not be that wrong. Why can't you simply use eAllContents() for your > traversal and you once more have your tree-recursion? Then we have a worse problem, sorting out the elements we want to render from the rest. For example all MPart's can have multiple menus but we certainly don't want to render them when rendering the part. In any case I'm not dead set against it, but it's a bad idea IMO. Q: Why do we have a 'child' list at all rather than defining a discreet attribute for each container element? A: Because it makes writing the rendering engine simple!
Proposal for BindingTable#bindingContextId: ------------------------------------------- I'd propose that we use BindingTable#bindingContext: BindingContext instead of using String referencing. We need to solve the String vs. Object referencing for contribution anyways so why using Strings here?
Created attachment 164625 [details] Proposal for Trim This is proposal to add trims by making them a frist class concept modeling it as a special container
2nd proposal on String vs Object references: -------------------------------------------- The proposal in comment 46 has the drawback that we need to identify the features before hand who can be affected by this String vs Object reference dilema. I discussed this with Boris and he came up with another solution: We could add a special attribute to ApplicationElement which marks it as reference which needs to be resolved to the real object when the model is loaded so the 2nd possibility to solve the problem add an ApplicationElement#surrogate: boolean.
I've just checked in the changes from the trim proposal. 2 things left: a) Paul any objections to make BindingTable#bindingContextId a Object reference (we need to find a solution for referencing anyways)? b) How do we want to implement Object-Referencing in terms of Contribution?
(In reply to comment #53) > I've just checked in the changes from the trim proposal. > > 2 things left: > a) Paul any objections to make BindingTable#bindingContextId a Object reference it's fine as long as it supports the ability to come in through model contributions. PW
I have one more change. I'd like to redefine Window#mainMenu to Window.mainMenus which is a multi-valued feature. Any objections?
(In reply to comment #55) > I have one more change. I'd like to redefine Window#mainMenu to > Window.mainMenus which is a multi-valued feature. > > Any objections? Or probably we should name it Window#menus so that is named the same than it is in Part.
Checked into HEAD. I'm scheduling a build for 14:00 (more or less) PW
Build successfull so I think we can close this one.
Yep, looks good....thanks all !! There are, of course, defects showing up that are the result of the switch but they can be addressed separately.
