For those that synch from HEAD or folks that will be picking up tomorrow's I-build there has been a major refactoring of the UI Model (UIElements.ecore).
Feedback is welcome, just add your comments to https://bugs.eclipse.org/bugs/show_bug.cgi?id=296478. MUIElement:: the old 'visible' attribute is now called 'toBeRendered' the old 'factory' attribute is now called 'renderer' the 'visible' attribute will be used indicate whether or not a particular element is actually visible to the User (matching the 3.x 'PartVisible' event) MUIItem has been renamed to MUILabel (to avoid confusion with MItem) the 'name' attribute has been renamed 'label' The model has been thoroughly cleaned to remove elements that we won't be using. We've decided not to use the 'IDE' containment structures (EditorStack, ViewStack...) for the compatibility implementation but will instead use the simpler 'RCP' (Part based) model, hopefully bringing us closer to being able to re-use legacy parts in basic RCP apps. The model has also been re-organized to group the model elements into 'packages' which provide a particular piece of functionality: For now the packages are simply marked with place holders in the model but Tom Schindl has kindly offered to turn them into 'real' EMF packages once we're satisfied that the structure is OK (as well as cleaning up some of the code generation options). Data Layer: Abstract elements used to construct the actual model elements using a 'mix in' pattern. Basic Elements: These can be used to build simple applications Menus and Toolbars: All the elements related to the modeling of basic menus and toolbars RCP: A part based definition allowing for a Sash/Stack arrangement whose leafs are MParts Advanced Elements: These can be used when the application developer needs extra capabilities. This allows the builder of an application to 'buy in' by using elements from the following packages. The packages are orthogonal, allowing the developer to, for example, use 'Trim' elements without having to pick up any (to him) unnecessary baggage. Commands: The Commands/Handlers infrastructure. This allows advanced features like Key Bindings, menus extension points...we'll be using this in the compatibility layer to re-implement the current 3.x menu handling. Trim: Provides the ability to add TrimContainers on any side of the MWindow. This is useful for supporting 'main' ToolBars as well as Status lines... Editors: Used to handle editors. This is different from the basic SaveablePart in that it provides an 'inputURI' to allow the editor to be based off of a resource (or other external) storage. Coming soon!! Shared Parts: allows E4 to implement the current Perspective behavior of re-using the same control (Tree...) in different places rather than new instances. Frames: The E4 equivalent to Detached Windows; separate Shells associated with the 'main' shell whose visibility is determined by their location in the Model (i.e. visible when the perspective that they're defined in is 'on top'. Onwards, Eric
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
