Bugzilla – Full Text Bug Listing
| Summary: | A SashForm replacement | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Thomas Schindl <tom.schindl> |
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | contact, emoffatt, Lars.Vogel, psuzzi, remy.suen, s.muecke, yves.yang |
| Version: | 0.9 | ||
| Target Milestone: | 4.1 M3 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Attachments: | |||
A feature we'll probably want to introduce is the have areas with a fixed width/height. Created attachment 176553 [details]
Sash replacement that doesn't use Composites at all
Here's a slightly different approach...to use it create a PDE project using the 'With a View' template (this is my easy way to get SWT snippet support...;-) and unzip the three classes into its source area (fix the package declarations).
Now just run the 'TestSashes'...
Features:
- *No* composites: all the 'stacks' are children of the shell's client area (this will help *a lot* with the resize behavior by removing the nested SashForms)
- 'Corner' dragging: you can drag the intersection of multiple sashes at the same time.
The layout has been specifically designed to use only information we already have in the model. The expectation is that we'd actually (re)write the layout to directly go against the model (i.e. the layout's 'root' would be an MPSC...).
We do need to be able to have finer grained control over whatever layout we come up with (another reason not to use SashForm), we had support for both minimum and maximum width/height (through ISizeProvider?). Also, if you resize the 3.x window notice that the only part of the layout that changes size is the Editor Area (grants all the extra space to the EA on a maximize). This is optimal behavior and we should be capable of emulating it... well at least on OS-X the background flickers very much when dragging sashes update the problem are the setRedraw() calls in the SashLayout#layout removing them makes thing behave appropriately on OS-X. Eric I think we should check in this change stuff into "org.eclipse.e4.ui.widgets" then we can work with it much easier. That this is really a nice implementation and will make our UI much more flexible and easier. Things coming to my mind for implementation: * we need to deal with things like fast views (=hidden areas overlapping others when activated = dealing with z-index of a control) * as you also mentionned min/max sizes (relative and absolute) * animation e.g. maximizing/minimizing in an animated way In future we should probably think whether we could push this new layout to SWT or are the things we do here too specific for the workbench? I'm currently fighting (yet another) sash form layout issue. I'll check a version of the layout into the e4 widgets project very soon so that we can start to look at some of the polish issues. The one technical issue is that the Sash 'Renderer' will no longer actually produce a 'widget'. The current protocol in createGui checks to ensure that the widget is non-null so we'll have to do something here, even if it's just adding an arbitrary value to the 'widget' field. Also, not that we have an actual 'shared area' we have two different composites that will each need their own instance of the layout...windows (client area) and MArea's composite. Also the resulting layout has to be able to manage a layout whose root is *not* an MPSC; the MArea for example initially only contains an MPartStack... While SWT might be interested in this I doubt they'll pick it up as part of the regular SWT release, is there a place (nebula?) where such SWT extensions can be placed (it does seem as if this would be useful to other folks, I'd hate to lose it completely..;-). Created attachment 179782 [details]
Patch replacing the current sash implementation with one based on the second layout
This is a very comprehensive patch:
- Replace SashRendering with a new layout (MPSC's no longer use widgets). This affected all potential sash containers (MWindow, MPerspective and MArea).
- Adds an implementation for a 'shared area' based on the new MArea element (includes changes to the MinMaxAddon to account for the new area)
- Contains changes to the various drop agents to perform layouts where necessary
- Removes spurious/commented sysouts
Created attachment 179783 [details]
Patch to fix failing tests
There were failing tests against the Sash rendering. I've removed the parts of the tests that relied on the rendered sash being a SashForm...
Created attachment 179786 [details]
Uber patch containing both the other patches
Committed in >20100928. Applied the patch. There is still one known layout issue...if you split the bottom stack to have two stacks one above the other and then drag it back the layout is incorrect but resizing the window fixes it. Some feedback on the new implementation: The sashes are no longer 'independent'. For example, when you change the size of the Package Explorer in 3.x (with the default perspective layout), the size of the Outline will not change. With the new implementation, however, the whole layout is affected, that is, the Outline will be resized too. I find this very annonying. It always bugs me when I experience such behavior in other applications. Would it be possible to tweak this with a model option? Created attachment 179870 [details]
Allow an MPartSashContainer to be 'shared'
Remy pointed out that the new rendering story made our old (non area-based) editor area story unsupportable, even though it was a valid 'shape' (model structure).
This is a surgical fix that specifically allows for this case (an MPSC as a shared element) work.
I wonder why the widget of SashFormContainer is a Rectangle. Where we can find its SWT Widget ? The VDE relies so much SashForm to edit the e4 parts. This change impacts a lot of changes in VDE. Verified in I20101026-0203. |
Created attachment 172629 [details] Project Here's the start of a widget which could replace our nested nesteted, ... Sash to get the workbench layout. Currently it only provides East-West and Nort-South resizing but it should be quite trivial to implement corner resizing, ... .