Re: [e4-dev] MCompositePart has been added to the UI Model

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

Wim, we currently don't have any way to correctly model a part that has an internal structure (MPart is a leaf). In the IDE there are at least three candidates that might want to use this:

PageBookViews - This is the Outline or Console view where there can be a number of 'pages' which are really sub-parts but only one is visible at a time
MultiPageEditorParts - This is like the manifest/plugin.xml editor where there are sub-parts in a tabbed stack
CompareEditors - This is what you get when you compare files...wouldn't it be nice if the left side of a compare was a *real* java editor ?

I'm sure that similar use cases can be found for RCP apps once the capability is available...

Thanks for the input on the issues, I'll wait for a while and aggregate them for a final discussion.

Eric

Wim Jongman ---07/30/2013 10:30:16 AM--->  This adds a new element MCompositePart into the UI Model. It's a > combination of both an MPart a

From:	Wim Jongman <wim.jongman@xxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date:	07/30/2013 10:30 AM
Subject:	Re: [e4-dev] MCompositePart has been added to the UI Model
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev