| Summary: | [regression] Perspective switcher does not allow to reorder prespectives | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Oded Arbel <oded> | ||||
| Component: | UI | Assignee: | Eric Moffatt <emoffatt> | ||||
| Status: | VERIFIED FIXED | QA Contact: | Eric Moffatt <emoffatt> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | andcoz, archana.acharya01, atte.kemppila, christopher.barber, daniel.rolka, dev, ebgz987, eclipse.sprigogin, flexx, hanriseldon, krzysztof.daniel, malaperle, mamacdon, masiegelmtr, mikewse, nbaccount, nobody, numeralnathan, piotr.aniola, piotr.findeisen, pquiring, pwebster, remy.suen, robertomarin, romeara, spamdefence+eclipse_bugs, sslavic, sudol.wojciech, tomasz.zarna, walderik | ||||
| Version: | 4.1 | Keywords: | helpwanted | ||||
| Target Milestone: | 4.4 M2 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 415234 | ||||||
| Attachments: |
|
||||||
|
Description
Oded Arbel
Trim dragging is not supported yet at the moment. I guess it's too late for Juno, but a workaround might be to allow sorting of perspectives in the Preferences/General/Perspectives and get that into 4.2.1 or 4.3M1? I reckon this might be easier to implement and would allow users to have a more desirable/predictable behaviour when closing and opening perspectives frequently. To me personally this is quite a "pet peeve" in 4.2 as of now, even though I mostly run with the same set of opened perspectives most of the time, with the "absolute ordering" being stable. That is, I don't need drag & drop if, for example, the debug perspective will always open between the java and firebug perspectives, if you know what I mean. ;) Thanks for the suggestion. Having 'Up' and 'Down' buttons on the pref page is a good idea. It might turn out to be even easier to do this the 'e4' way: Add a command that will move a given perspective forwards or backwards in the list. I think we need two commands to allow is to have two bindings. Make sure that the Perspective Switcher correctly updates. Make sure that no spurious rendering or activation is taking place. The idea was to do this at the same time that we implement the ability to drag tool items around but it looks like that will have to wait to 4.3... (In reply to comment #3) > Thanks for the suggestion. Having 'Up' and 'Down' buttons on the pref page is a > good idea. It might turn out to be even easier to do this the 'e4' way: > Eric, in the short term will re-ordering the perspectives in the model update the perspective switcher? If so, it could possibly be done with the live model editor. PW *** Bug 347371 has been marked as a duplicate of this bug. *** I figured out you can actually reorder them by using the up and down arrows in the perspectives in the live application model view. Took it to the limit and spawned some IAE from o.e.ui.internal but I actually reordered them by my needs. If the current implementation can't handle reordering it can easily be made to do so... How about this for the first pass ? We supply two commands which can be used to moves a perspective forwards / backwards through the list of perspectives. If no perspective is specified then the currently active perspective is used (so that folks can use this through Quick Access). (In reply to comment #7) > How about this for the first pass ? > > We supply two commands which can be used to moves a perspective forwards / > backwards through the list of perspectives. If no perspective is specified > then the currently active perspective is used (so that folks can use this > through Quick Access). I'd +1 this, I'd really appreciate it. And it should easy enough to implement (and test) for 4.3M4 even? In fact, if this was possible, then drag & drop could be seen as something to redo whenever there's time, even post-4.3 IMHO. +1 (In reply to comment #9) > +1 Please cast your vote. Anybody up for doing a patch ? Basically make a command that: 1) Finds the MPerspectiveStack 2) Gets the current selected element 3) Moves the element that is *next to* the selectedElement before or after the selected element depending on which direction we're moving the current perspective NOTE: Coding this up to move the non-selected element will result in a much smoother transition since removing / adding the currently selected element is likely to flicker even if you reset it afterwards... I will try to create a patch for this. *** Bug 404182 has been marked as a duplicate of this bug. *** This is a regression from 3.x. Please give it high priority. Any ideas how I can access the MPerspectiveStack from the command handler? I tried having it @Inject-ed, but apparently, it's not in the command's event context. (In reply to comment #15) > Any ideas how I can access the MPerspectiveStack from the command handler? > I tried having it @Inject-ed, but apparently, it's not in the command's > event context. Where's the command handler? At the Window level, or Application level? Is it an Eclipse4 command handler or a subclass of AbstractHandler? PW I added the handler in org.eclipse.ui.internal. The handler is a Eclipse 3.x-style handler, subclassing AbstractHandler. (In reply to comment #17) > I added the handler in org.eclipse.ui.internal. > The handler is a Eclipse 3.x-style handler, subclassing AbstractHandler. IWorkbenchWindow window = HandlerUtil.getActiveWorkbenchWindow(event); Then MWindow model = window.getService(MWindow.class); EModelService modelService = window.getService(EModelService.class); MPerspectiveStack perspectiveStack = modelService.findElements(model, null, MPerspectiveStack.class, null); PW We'll fix this one in luna... (In reply to comment #19) > We'll fix this one in luna... This is very very unfortunate since this is a regression from 3.8. Please reconsider. http://wiki.eclipse.org/Platform_UI/Plan/4.3 describes the priority list of what we're trying to fix for 4.3. This just isn't high enough priority. PW Created attachment 230945 [details]
partial patch
I created a patch that flips the perspectives in the MPerspectiveStack (so far only flipping "forward").
The perspectives being switched are not the ones I would expect - the order of MPerspective objects in the MPerspectiveStack does not match the order displayed on the screen.
What is the mapping between the objects in the model and their screen representation? I checked the classes PerspectiveStackRenderer and StackLayout, but no methods from these classes are invoked when the perspectives are swapped on the screen.
Please consider fixing this in 4.3.1. I'll tag it for the service release but no promises...if there are other gating defects this may get pushed back... Eclipse Kepler also has the same problem. Wojtek, it looks like Eric has a solution for this problem. PW Changing milestone since the first commit will be to master... Committed http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=29cfa0e28e182fe7fdbf42512452f183afa1828f This implements a (fake) drag and drop to move the perspectives around. There are currently two issues we've seen: 1) If you drag the active perspective then the drop causes a flicker as the main toolbar recalculates its state (fairly minor IMO) 2) We've seen a *very* strange effect where the image for an item will change into some other image (like the drop-down triangle or some other toolbar's button's image). I can't seem to get this using the current code but please re-open the defect if you see this or other issues... Once this gets into a build we should try it on all the platforms to ensure its behavior is OK. I'll likely want to make a couple of tweaks before we back port this: 1) It turns out that we do get a 'DragDetect' event from a ToolBar, we should use this rather than my current hard-coded 'DRAG_TOLERANCE' approach 2) The reason that the text appears below the image on the drag image is that the ToolBar I construct needs the SWT.RIGHT flag set... (In reply to Sopot Cela from comment #6) > I figured out you can actually reorder them by using the up and down arrows > in the perspectives in the live application model view. Took it to the > limit and spawned some IAE from o.e.ui.internal but I actually reordered > them by my needs. In Kepler (4.3) I didn't see the Live Application Model View in the list of Views, but it did show up with Ctrl-3. I found the perspectives under Windows -> Trimmed Window -> Controls -> PartSashContainer -> Perspective Stack. I had to restart Eclipse for the changes to take effect. Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2a9641a52fcc58703882ed492852437f52d24313 Applies the tweaks outlined in comment #29. There are still some remaining issues on Linux that Paul and I will look at tomorrow... Verified in the build: I20130916-2330-win32 With this fix reordering of perspectives provides much better visual feedback on GTK than reordering of editor tabs (bug 404684) or reordering of toolbars (bug 419803). Maybe the other dragging operations can be improved based the ideas used for the perspective switcher. After re-testing on Paul's machine the issues we were seeing have gone away... *** Bug 424883 has been marked as a duplicate of this bug. *** Verified in I20140528-2000. |