Community
Participate
Working Groups
F1 is universal shortcut for Help. In Eclipse this key opens Help as the most right position View, very nice look. After using detached View for Help, 1) I drag-and-dropped into onto Windows Taskbar, but the detached View became out of desktop area (I only could see it under Taskbar because I have Aero (transparent) theme) 2) After unfixing Taskbar, moving Taskbar, moving detached View for Help, moving Taskbar back, I played a little bit with the View and closed it. Now when I press F1 nothing happens.
Please provide some function for managing Windows.
Maybe something like a "Snap all Shells to Display(0,0)" PW
I'm not 100% sure I've understood the steps to repro. This is what I did in Eclipse Luna I20140606-1215: - pressed F1 to make the Help View appear - detached the Help view - dragged it on the Windows Taskbar (why should I do that?) - unlocked and moved the Windows Taskbar to another screen side - moved back the detached window near the center of the screen - moved back the Windows Taskbar in it's original position - made some clicks in the Help View - closed the Help View (either with the "X" in the view tab or with the "X" of the detached view) - hit F1 again In all my tests, the detached window was shown again in the position where it was before closing and the Help View was correctly present in it. So, unless more detailed steps to reproduce are provided, I think this is not valid any more in Luna. Regarding comment #2, see bug #334331.
It is bug. And it is still present in Luna 4.4 On Windows drag-and-drop tab onto Task Panel is a way to detach View into a Window. I just did it with my Firefox tab. When drag-and-drop Eclipse View on Windows Task Panel it becomes new Window with X,Y coordinate of left-top corner where I just dropped. As Windows Task Panel is uppermost, it hides all window beneath. So users that may be unaware of that will find detached View missing (the View will reappear under hidden position when opening View again via Window -> Open View.) Window menu does not have any commands to arrange windows or give a windows list. Back to Firefox example, Firefox opens tab in a new window next or in maximized window if original window was maximazed.
Ok, so now I understand why you're dragging on the task bar: because you have your Eclipse main window maximized. I also see the problem that dragging on the task bar makes the detached window stay under it, unreachable. This is a problem, although I think a minor one (workaround: restore the main window, so that it's not maximized any more, and drag your view outside its frame to detach it and leave it reachable). However I still can't reproduce your second point in Luna: after moving the taskbar on another side, the detached view becomes immediately visible to me (it's moved near the center of the screen). I can even move it around: if I then close it and reopen with F1, it will be shown again in the exact same position it had when I closed it.
(In reply to Mauro Molinari from comment #5) > However I still can't reproduce your second point in Luna: after moving the > taskbar on another side, the detached view becomes immediately visible to me > (it's moved near the center of the screen). I can even move it around: if I > then close it and reopen with F1, it will be shown again in the exact same > position it had when I closed it. Yes, if the use knows how to make Windows taskbar movable and move it aside, he can find the detached View. And it will be restored there if closed. The problem is that View should not be restored in unvisible area. E.g. you have View closed, then you plug projector VGA connector, your screen resolution changes to that of projector, now if the View is restored it will be not visible. This example was not tested, but demonstrates that when View is restored Eclipse workbench should check whether the location is actually inside visible and accessible area.
The case of multi-monitor is covered by bug 236054, which, on the other hand, seems to be reproducible only on Windows (although I've not tested with Mac). However I think these two issues are related, but not the same: in this case, the window is actually in a visible area, but covered by another UI element on top of it. I think that this should be handled by: a) an explicit support for the use case "drag on the task bar" to detach a view b) provide some sort of window management for detached views However this is just my personal opinion.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
