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

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

Tom, thanks for the input on the iisues, especially the comment about 'nervous' toolbars and the DnD implications which I'd totally forgotten about...

Eric


Tom Schindl ---07/30/2013 01:12:57 PM---Von meinem iPhone gesendet Am 30.07.2013 um 16:29 schrieb Wim Jongman <wim.jongman@xxxxxxxxx>:

From:	Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Cc:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date:	07/30/2013 01:12 PM
Subject:	Re: [e4-dev] MCompositePart has been added to the UI Model
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

Von meinem iPhone gesendet

Am 30.07.2013 um 16:29 schrieb Wim Jongman <wim.jongman@xxxxxxxxx>:

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?

Did you see the split editor demo Remy and me already did at many places?

Tom

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