Community
Participate
Working Groups
It is possible for the shared area to be have views in them. If a view is the selected element and is blocking the other editors behind it, there is no active editor and Ctrl+E will not work.
Bug reproducible also in Oxygen. steps: - Close all editors in "editor area" - move the Problems and Console view in "editor area" - Press Ctrl+E: nothing happens (I expect I can switch between Problem and Console) - open an Editor in the Editor Area - Press Ctrl+E: you can now switch between Problem, Console, and Editor. details: Eclipse SDK Version: Oxygen (4.7) Build id: I20160803-0800 OS: Windows 10, v.10.0, x86_64 / win32
I've set version back, because it indicates the *first* version where the bug was observed.
Thanks!
Analysis: In org.eclipse.ui\plugin.xml, M1+E is linked to the command org.eclipse.ui.window.openEditorDropDown. The command is handled by the class org.eclipse.ui.internal.WorkbookEditorsHandler. The handler is enabledWhen the variable="activeEditor" is <instanceof value="org.eclipse.ui.IEditorPart"/> To switch between all the parts in the editor area, we should consider checking activePart, instead of activeEditor, see [#1] [#1] http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fworkbench_cmd_expressions.htm
New Gerrit change created: https://git.eclipse.org/r/81850
With the provided change you can switch among all the tabs in the current stack using a filtered list. See: http://i.imgur.com/yc2t3WL.gif
Gerrit change https://git.eclipse.org/r/81850 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4e76ababa7044cdb45c74e486a9efa23eb643a7c
The fix is in master now. After this fix, we should solve bug 502123.
I think this should be added to the N&N M3.
New Gerrit change created: https://git.eclipse.org/r/81955
I'm not sure if the change in the shortcut is desired. Currently with Ctrl+E I can access the elements in the editor area. With your change (at least on Windows), it allows me to select parts of the active stack. I can image this change would break the workflow of people. I think Remy original request was to cover also views in the editor area. I think we should keep the previous behavior. Or, if you want to change this behavior, you should ask for additional feedback on the platform UI mailing list.
I see what you mean. I introduced a regression because Editors and Views are now selected in any part stack, and this is wrong. I'm going to fix the regression by limiting the selection in the EditorArea, as it was before.
After analysis, this is how I'm going to implement the fix: At Ctrl+E, get the active part and find stack containing that part. - If the stack is contained in the EditorArea: show the filtered list with editors and views in that stack - If not, show the filtered list for the primaryDataStack in the EditorArea
(In reply to Patrik Suzzi from comment #13) > - If the stack is contained in the EditorArea: show the filtered list with > editors and views in that stack > - If not, show the filtered list for the primaryDataStack in the EditorArea I don't understand the difference. Why not always use the same approach?
Precisation: (In reply to Lars Vogel from comment #11) > (..) Currently with Ctrl+E I can access the elements in the editor area. Not only, but in any PartStack containing an Editor. See http://imgur.com/r8syFnD.png Back to the point: (In reply to Lars Vogel from comment #14) > I don't understand the difference. Why not always use the same approach? I analysed the code: (1) The previous implementation uses getActiveEditor() - does not work in case of Views (Bug!) - does show the List in any PartStack containing the active editor. (2) The current implementation uses getActiveView() - works both for View and Editors (Fix) - does show the List in any PartStack containing the active editor or view. (not expected) Assuming that (2) is not the expected behavior, I think the current approach is limited. Indeed, We need to know when the current part stack contains no editors - if it has editors, we should show the list for the current part stack - if it has no editors, we should show the list on the PartStack which contains the last opened editor( or, more simply, in the primaryDataStack ) Any suggestion would be greatly appreciated. I'm willing to spend more on this, if this will help the User Experience.
My suggestion for a consistent behavior of Ctrl+E would be: 1.) Ctrl+E shows ALL editors no matter in which place of the IDE they are. 2.) If views are in the editor area, Ctrl+E also shows them Dani, Andrey, does that make sense to you?
(In reply to Lars Vogel from comment #16) > My suggestion for a consistent behavior of Ctrl+E would be: > > 1.) Ctrl+E shows ALL editors no matter in which place of the IDE they are. > 2.) If views are in the editor area, Ctrl+E also shows them > > Dani, Andrey, does that make sense to you? 1) Yes. 2) No. Ctrl + E is show editors, not views "Open the editor drop down list". So independently where the editors were embedded, Ctrl+E should show all of them, and only them.
(In reply to Andrey Loskutov from comment #17) > 1) Yes. > 2) No. Ctrl + E is show editors, not views "Open the editor drop down list". > So independently where the editors were embedded, Ctrl+E should show all of > them, and only them. +1 sounds good to me
(In reply to Lars Vogel from comment #18) > (In reply to Andrey Loskutov from comment #17) > > 1) Yes. > > 2) No. Ctrl + E is show editors, not views "Open the editor drop down list". > > So independently where the editors were embedded, Ctrl+E should show all of > > them, and only them. > > +1 sounds good to me +1 good for me too. My initial idea is to implement it like in Ctrl+F7, but adding a filter.
(In reply to Patrik Suzzi from comment #19) > My initial idea is to implement it like in Ctrl+F7, but adding a filter. Ergo: to implement it like in Ctrl+F6 plus adding a filter.
(In reply to Patrik Suzzi from comment #20) > (In reply to Patrik Suzzi from comment #19) > > My initial idea is to implement it like in Ctrl+F7, but adding a filter. > > Ergo: to implement it like in Ctrl+F6 plus adding a filter. +1 and afterwards fix Ctrl+F6 to use the same class, so that we have less code and filter options via both shortcuts. Filter in Ctrl+F7 would also be nice.
New Gerrit change created: https://git.eclipse.org/r/82333
Ctrl+E dialog is completely re-done using the approach used in CycleBaseHandler. The user can now filter a table displaying a list of all the open editors. I tested the table in dark theme also and looks decent. The filtered table can be transformed into a cyclable list just by changing the flag in WorkbookEditorsHandler#isFiltered(). I also tested the cyclable list in dark theme and looks ok I can easily switch the Ctrl+F6/F7/F8 implementation by extending FilteredTableBaseHandler instead of CycleBaseHandler. Note: the list of CycleBaseHandler looks bad in DarkTheme, but the Cyclable list of FilteredTableBaseHandler looks better.
Created attachment 264532 [details] Comparison between classic and dark theme, in windows. Now the filter looks ok both on classic and Dark theme. For comparison purpose, below you can see how the Ctrl+F6 currently looks in Dark Theme: https://bugs.eclipse.org/bugs/attachment.cgi?id=264527
Created attachment 264533 [details] Anim Gif demonstrating the current behavior The attached anim gif demonstrates the behavior of the new (proposed) Ctrl+E dialog. Notes: - It's easy to auto resize the height of the dialog at each keystroke. [#1] - It's easy making the dialog user-resizable, bug shells with SWT.RESIZE style look bad on dark theme.[#2] #1 http://i.imgur.com/t4qicsi.gif #2 http://imgur.com/D2QMXKW.png
The change is ready for production. As I added ~900 lines, It would be great having a review before submitting it.
*** Bug 502123 has been marked as a duplicate of this bug. ***
(In reply to Patrik Suzzi from comment #26) > The change is ready for production. As I added ~900 lines, It would be great > having a review before submitting it. Patrik, sorry, I have no time for that.
No problem, thanks! I know most of us are busy people :) As I said, the code is production ready, then m going to merge it shortly, so we can see the new Ctrl+E soon in Oxygen.
Gerrit change https://git.eclipse.org/r/82333 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d4c2095a88134621f024495f737c7d193fb8e958
In master now. See the behavior here: https://bugs.eclipse.org/bugs/attachment.cgi?id=264533 The change fixes also Bug 502123, hence you can keep pressing Ctrl+E to cycle through the list (similar to Ctrl+F6). Additional improvements: - You can cycle the list also by pressing arrow keys - The change is theme friendly
New Gerrit change created: https://git.eclipse.org/r/82462
Gerrit change https://git.eclipse.org/r/82462 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=5064cfc135870a64d69264183a464972577a5247
*** Bug 497937 has been marked as a duplicate of this bug. ***
