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
From: Wim Jongman <[email protected]>
To: E4 Project developer mailing list <[email protected]>,
Date: 07/30/2013 10:30 AM
Subject: Re: [e4-dev] MCompositePart has been added to the UI Model
Sent by: [email protected]
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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
