Community
Participate
Working Groups
In 3.7 it is possible to move a minimized stack by dragging it to some other position in the workbench. This does not seem to be possible in 4.1
Yes, this is on my list...;-). I was hoping to handle this along with dragging ToolBars but I think I'll have to do regular 'trim' dragging first...
Setting milestone...
Pushed in >20120130. Two commits to get set up to do the trim dragging... commit 67c4d1cce8a0aa6c8c3774418383a69c313046f1 (add ImageBasedFrame) commit d8bef7f37097fe7193a1dc824e007b1f28a16d5c (update CSSRenderingUtils for framing)
*** Bug 327893 has been marked as a duplicate of this bug. ***
Changing the title to better reflect the scope of the defect (i.e. this defect also applies to being able to drag both MToolControls and MToolBars around the trim...
Pushed two commits in >20120222. 1) TrimStack Dragging Implementation commit e7c84cbc7fad391496bdb887bbdbd002e214ebf1 2) Adjusting the location of the trim 'pane' to handle all sides commit a8bcf7b152aff4ce07f00499d9a60caabbccb1ee
I believe the work on this defect has introduced an ArrayIndexOutOfBoundsException when a workspace is started with NO perspectives open. I believe the real issue is similar to the one described in Bug 361672
I see that an assert is used before the offending code. Is this really a sufficient check since java ignores asserts at runtime unless the -ea option is specified?
commit b2cb908e226851e81f06a7b15f0af0ed9e210a8c This is just initial work getting set up for dragging Toolbars in the top trim...this code is a no-op until we check in the changes to the CSS file(s). Until then the new 'frameMeIfYouCan' call will simply return the control that it was passed... Note that going forward we'll have to remove the current 'intermediate' composite code in favor of using the ImageBasedFrame...
Forgive my ignorance, but will this work include the Perspective Switcher and Heap Status?
(In reply to comment #8) > I see that an assert is used before the offending code. Is this really a > sufficient check since java ignores asserts at runtime unless the -ea option is > specified? Agreed. This assertion is insufficient.
Eric, forgive me but with all the best of intentions this will have to wait until (at least) 4.2.1.
(In reply to comment #12) > Eric, forgive me but with all the best of intentions this will have to wait > until (at least) 4.2.1. So that means the Perspective Switcher will not be movable in the Juno release? I completely understand the insufficient people and time problem, but to be honest, isn't this a regression from work done earlier in the 4.2 release cycle? Where is the process that should prevent such regressions?
+1 to fix ASAP. It's just personal opinion and not a demand on our product. I was a bit confused when I brought up M7 and saw this missing as it's one of the first things I do on a new install.
*** Bug 383606 has been marked as a duplicate of this bug. ***
*** Bug 383912 has been marked as a duplicate of this bug. ***
*** Bug 314163 has been marked as a duplicate of this bug. ***
*** Bug 385568 has been marked as a duplicate of this bug. ***
commit b5a24411e872c0006c0c1d8970bd74e551767805 This is a *major* commit, more testing is required ! I've had to change the CoolBarToTrim manager substantially as well as a lot of the layout code... This is only Part 1...there are still a number of known issues: - Removing the composite that used to wrap the managed TB's introduced an NPE in the stack activation handling (Because of focusing issues ??) - TB's docked in vertical trim don't go vertical yet. - A very odd effect is that when the cursor is over the *left* side of the 'spacer' (i.e. the space left by right adjusting the Search) the drag element is docked at the end of the trim bar rather than before the Search, not at all sure why yet. - Dragging near the bottom of the top trim bar will also dock the control to the far right (it expects the only time the cursor to be over the trim's composite is when you're 'off the end' of the trim).
commit 907dfcab9a0bf18d27063d4a324bdecf299929cb This fixes the NPE in the StackRenderer (but I'm still wondering why such a simple change caused this in the first place...).
Created attachment 219501 [details] New (alpha adjusted) drag handle John, in order to complete the puzzle I'll need you to do two things in the platform repo: 1) put the attached image in platform's 'images' folder with the name 'dragHandle.png' 2) Copy the code below and put it at the end of 'e4_basestyle.css' .MToolBar.Draggable { handle-image: url(./dragHandle.png); } .MToolControl.Draggable { handle-image: url(./dragHandle.png); }
Adding John to the CC list...
(In reply to comment #21) > > John, in order to complete the puzzle I'll need you to do two things in the > platform repo: Done: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=0121b17560048a0fb02658a32479367d2a2fa808
Just reproduced a scenario in which the perspective switcher (PS) disappears forever (until window-new window): - Take the PS to the rightmost vertical trim (the whitespace on the right in the attachment) - Take it from there to the upper window trim (near the _[]X like in the screenshot). The (/) icon appears to show you can't release it but if you do, the switcher is gone forever.
Created attachment 219507 [details] PerspectiveSwitcher bug sshot
Also while messing with the status line at the bottom i got a widget disposed on Control[] kids = lines.get(0).ctrls.get(0).getParent().getChildren(); Stack: at org.eclipse.e4.ui.workbench.renderers.swt.TrimBarLayout.ctrlFromPoint(TrimBarLayout.java:309) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.getInsertionElement(TrimDropAgent.java:86) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.track(TrimDropAgent.java:165) at org.eclipse.e4.ui.workbench.addons.dndaddon.DragAgent.track(DragAgent.java:112)
I think the commits done on 8/2 have broken the layout of toolbar. The spacers are missing and there is odd whitespace. See the screenshots I posted on the forums: http://www.eclipse.org/forums/index.php/mv/msg/357586/902025/#msg_902025
(In reply to comment #27) > I think the commits done on 8/2 have broken the layout of toolbar. The > spacers are missing and there is odd whitespace. See the screenshots I > posted on the forums: > http://www.eclipse.org/forums/index.php/mv/msg/357586/902025/#msg_902025 It's broken with the 'Windows 7 Classic' theme, not 'Windows XP Blue'
(In reply to comment #28) I had same problem. Bug 389594 as well. It is because comment 23 doesn't affect css files having no @import url("e4_basestyle.css"); e4_classic_win7.css,e4_classic_winxp.css,e4_default_winxp_olv.css.
Toshihiro, great pickup...I'll get someone on this right away !
Bogdan, once you have a few minutes could you look into this one. It should be pretty straightforward...
Eric, I suppose this did not go in as in 4.2.1 if you change to classic theme you get no trim dragging and broken layout.
(In reply to comment #31) > Bogdan, once you have a few minutes could you look into this one. It should > be pretty straightforward... Fixed this in master and R4_2_maintenance. http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=e38de2f54fe88bc617776385822419d76ca29021 http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?h=R4_2_maintenance&id=b26e73e82245d13948e7d6174d17334301bb93b3
*** Bug 389594 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > > Fixed this in master and R4_2_maintenance. > > http://git.eclipse.org/c/platform/eclipse.platform.git/commit/ > ?id=e38de2f54fe88bc617776385822419d76ca29021 > > http://git.eclipse.org/c/platform/eclipse.platform.git/commit/ > ?h=R4_2_maintenance&id=b26e73e82245d13948e7d6174d17334301bb93b3 Is this fixed then? PW
Yes, closing as FIXED.
Created attachment 222989 [details] Possibly more issues around the same symptom? Sorry if posting to a fixed ticket is not kosher! (?) Anyway, the reason is to help with testing/verification, as my screenshot might include some other observations... I didn't see any mention of: - layout getting progressively worse (after each Eclipse restart?) - items being covered/drawn-over once the toolbar has wrapped. I'll try to pick up a milestone build when I get a chance (not for a few weeks - I'm travelling). WORKAROUND for anyone interested: switch to glossy new e4 appearence, restart, rearrange toolbar, switch back to Classic, restart.
Luke, no problem doing it, new info is always good. I'm testing 4.3M3 today so I'll switch over to the Classic look and test it out...
I've now seen the problem with the over-writing and I know the cause...it's a fix that I put in to prevent the 'spacer' control from over-writing the 'key line' at the bottom on the top trim. I'll re-open this defect...thanks !
I am also facing a similar issue as mentioned above, I have updated my eclipse but it is still there...
Is this still not being worked
Defered to 4.3
I used the patch as proposed and have a similar poor rendering. What I don't unterstand is that the host eclipse 4.2.1 DOES show icons properly arranged whereas the target rcp does not. However I noticed that the gaps are probably caused by invisible editor actions. Any hints, patches and workarounds are pretty welcome since we need to switch to 4.2.1 asap and this is really a show stopper for us.
I;ve just submitted a fix for the trim 'overwrite' issue so this may be worth checking again with M6 (or next week's I-build. I'll check myself tomorrow...
Created attachment 227140 [details] Patch to get rid of spaces in main tool bar The empty spacing is related to B#284388. Its rooted in tool bars that have no tool items but compute their size to 24,22. For me they are empty because of editorContributions that are currently not shown. The attached patch considers the size calculation only if there are tool items in the toolbar. The drag separators are still missing but at least the spaces are gone.
TrimBarLayout contains a special check for computeSize. Is this still necessary? The associated bugs seem fixed.
Is this still open in Eclipse 4.3 N20130218-2000 or later? I can't reproduce it anymore? The bug is getting relative long, so could someone give a description how to reproduce this issue, if it is still present?
This problem still exists in Eclipse Kepler 20130614-0229... or at least I haven't figured out how to move the elements.
The problem still exists in Eclipse Kepler Build id: 20130614-0229 on Windows 7. How is it possible for something blatant like this to make it into 2 major releases years apart?
Resource Constraints. Unfortunately there are numerous outstanding major bugs: http://wiki.eclipse.org/Platform_UI/Plan/4.3 Fortunately you can contribute and fix the bug :-)
Nathan / Anthony, using any of the standard CSS definitions (i.e. Windows 7) you should see drag 'handles' to the left of the toolbars. Hovering over one should sow the four-way arrow to indicate that you can drag the element...are you not seeing this ? I'm presuming you're trying to move the toolbars, if not then what are you trying to do ?
Created attachment 233384 [details] Perspective toolbar Eric, to be clear: the perspective toolbar (i.e. Java/Debug/SVN) is draggable as a toolbar. I can stick it between other toolbars, or before and after Quick Access. The individual perspective buttons on the toolbar are locked though. In other words, I cannot swap Java and Debug perspectives when they are open.
+1, 4.x regressed from 3.x in not letting me rearrange the order of my perspectives in the perspective bar
(In reply to comment #52) > Created attachment 233384 [details] > Perspective toolbar > > Eric, to be clear: the perspective toolbar (i.e. Java/Debug/SVN) is > draggable as a toolbar. I can stick it between other toolbars, or before and > after Quick Access. The individual perspective buttons on the toolbar are > locked though. In other words, I cannot swap Java and Debug perspectives > when they are open. (In reply to comment #51) > I'm presuming you're trying to move the toolbars, if not then what are you > trying to do ? I can move toolbars but that is not what I am trying to do. I would like to rearrange the buttons in the toolbars. For example, I might want to rearrange the buttons Debug, Run and External Tools on that toolbar.
OK, I'm closing this one again because it's all about dragging the toolbars, not their items... Let's move this thread over to bug 364046 which is specific to repositioning the items on the PerspectiveSwitcher... Nathan, I am trying to see whether we can extend the DnD code to include the possibility of re-ordering items in regular TB's but no promises (there are deeper issues here due to the complexity of the commands infrastructure).
