| Summary: | [design] Wrong view order after closing a view | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Beate M <beate.muellerleile> | ||||||||||
| Component: | Workbench | Assignee: | Project Inbox <rap-inbox> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P2 | CC: | holger.staudacher, michael.klein, mknauer | ||||||||||
| Version: | 1.3 | ||||||||||||
| Target Milestone: | 1.4 M7 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 292122 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Beate M
Created attachment 185699 [details]
Before closing a view
Created attachment 185700 [details]
After closing a view
Thanks for reporting this. The folder implementation of the designs is home grown. So, it will be replaced with the original CTabFolder when it is enough themable to fulfill the design requirements. I made this bug dependend of bug 292122 I think a new TabFolder implementation (bug 329681) would be more suitable as a replacement for the current design because the CTabFolder theming will always be limited due to it's server-side nature. At any rate, this bug should be fixed soon, whereas replacing the stack presentation seems to be a long-term effort. Created attachment 192078 [details]
Some improvements to reduce view shuffling
I've made some analyses to improve the view sorting (see patch).
There are still situations causing the views/editors to change their order (sometimes if a view/editor reappears after another view has been closed).
But I think the eye-catching shuffle after closing a view/editor is much better.
I don't know if the patch is worth to be committed to CVS because it doesn't solve the problem completely, but maybe it helps others to improve their situation or to make some further analyses.
Created attachment 192712 [details]
Proposed patch
Hi Michael, Beate. Could you test this patch? I think that it solves the problem completely. The solution is to not move the button in showPartButton if you close a part.
Fixed in CVS HEAD by changing the ViewStackPresentation#showPartButton to not move the button if it was visible before. I still get two errors: The first problem is: If a editor reappears (from overflow) it is always is inserted next to last. I think in my solution it appears at the end. The second error is a stacktrace which occurs when the last editor is closed: org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:3227) at org.eclipse.swt.SWT.error(SWT.java:3147) at org.eclipse.swt.SWT.error(SWT.java:3118) at org.eclipse.swt.widgets.Widget.error(Widget.java:954) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:890) at org.eclipse.swt.widgets.Composite.layout(Composite.java:326) at org.eclipse.rap.internal.design.example.stacks.ViewStackPresentation.showPartButton(ViewStackPresentation.java:756) at org.eclipse.rap.internal.design.example.stacks.ViewStackPresentation.access$6(ViewStackPresentation.java:748) at org.eclipse.rap.internal.design.example.stacks.ViewStackPresentation$8.widgetSelected(ViewStackPresentation.java:545) at org.eclipse.swt.events.SelectionEvent.dispatchToObserver(SelectionEvent.java:196) at org.eclipse.rwt.internal.events.Event.processEvent(Event.java:44) at org.eclipse.swt.events.TypedEvent.processEvent(TypedEvent.java:163) at org.eclipse.swt.events.TypedEvent.executeNext(TypedEvent.java:203) at org.eclipse.swt.widgets.Display.runPendingMessages(Display.java:1134) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1124) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2390) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2351) at org.eclipse.ui.internal.Workbench.access$5(Workbench.java:2206) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:424) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.jface.internal.databinding.realmadapter.RealmAdapter.run(RealmAdapter.java:44) at org.eclipse.rap.ui.internal.RealmAdapterHook.runWithDefault(RealmAdapterHook.java:48) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:427) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:157) I will reopen it to fix these issues. Hi Ivan, I'm a little bit confused.
Because you said "Fixed in CVS HEAD" I've tested against CVS HEAD.
But I couldn't find the changes from the patch you attached.
For example:
- private void showPartButton( final IPresentablePart part ) {
+ private void showPartButton( IPresentablePart part, boolean move ) {
Michael, I fixed it in a different way... to address the bug 316247 as well. The NPE when you close the last editor/view is fixed in CVS HEAD. Looking for a solution of the issue with positioning of the part button when reappears from overflow. Michael, as the original issue of this bug "wrong view order after closing a view" is fixed, would you mind to open a different bug for the active part button order when activating from overflow? Thanks Michael, please discard my previous comment. I've managed to reproduce what you described by closing a view part too. To reproduce it, open new editors till overflow appears and close the active view part. The new active view part button that comes from the overflow is position not on the last position, but on the previous. I think that this issue is finally fixed. Michael, I've incorporate your patch with some refactorings. Additional fix in ViewStackPresentation#futureTabChildrenSize for missing BUTTON_SPACING calculation has been added. |