> This adds a new element MCompositePart into the UI Model. It's a > combination of both an MPart and an MPartSashContainer; allowing a part to > contain a substructure. > Cool. Why is it added, what is the use case?
> > What does 'getActivePart()' mean now ? Possibilities include (at least): > > - The 'outermost' active part (i.e. the first one encountered walking > *down* from the window / perspective > - The 'innermost' one (i.e. the currently active leaf within the > substructure) > I would say that the getActivePart always returns the current active leaf. I would not want to change the paradigm of a single active part. > > - Perhaps a new API 'getActivePartChain' that returns an ordered list of > the 'active' parts ? > I would rather query the model for the MCompositePart of the unique active part. > > > How does the Commands infrastructure interact with the collection of > parts; if the various parts on the active chain define different (possibly > conflicting?) key bindings how are they and their handlers resolved ? > That complexity alone already rules out the idea of multiple active parts IMO. > > > If I have a CompositePart in a stack should the stack show the toolbar and > dropdown menu from the active leaf ? > This could cause a very nervous toolbar. IMO All the toolbars and menus should be gathered and placed on the MPC's toolbar/menu for all visible leafs. The icons and items should be grayed out when the leaf is not selected and the handler is specifically targeted to that leaf. > What other issues might come up ? > What about min/max for a leaf drag and drop of a leaf. - Can it be dragged out a MCP and dropped into another. - Can the leafs be rearranged in the MPC cheers, Wim
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
