Community
Participate
Working Groups
When undocking a view it always stays on top. This behaviour makes this "undocking feature" pretty useless for us. It should be possible to bring the app window into the foreground (at least optional). I see two ways to achieve this: - let the view implementor decide if the view should be ON_TOP or not (optional flag) - add a minimize button to the view window This applies to 3.2M4 and 3.1.1.
(In reply to comment #0) I prefer the first option, and would even argue that the !ON_TOP should be the default. But in any case, those of us writing our own Views would like to be able to make them not always on top.
This will either be covered as part of making the DW's first-class shells or making their visibility dependent on the activation of the 'main' shell. Giving fine-grained visibility control here will lead to users 'losing' their DW's.
For what it's worth, I agree with the original reporter, in that I think the use of detached views is degraded by them always being on top. I thought the purpose of the detached view was similar to the minimize/hide function of attached views - to free up screen real estate until the user actually wants to see the view. But obviously, if the view is still on top, no screen real estate is freed. So may I suggest that proper closure of this bug should include a description of what the intended use is for detached views? My apologies if this information is spelled out elsewhere...if it is, I think it should be linked to from here.
*** Bug 404963 has been marked as a duplicate of this bug. ***
Hello all. I am not pleased that the bug is now marked as: "Won't Fix". I'll address the big points after the important points. 1. The problem is not: "on-top". 1.1 The window is ALWAYS_on-top (you can't see the display) 2. Any non-dialogue window MUST be 'normal' -- That means exhibit the same behaviour of any other normal window (not a dialog or prompt, etc). Minimize, maximise, re-dock/undock, etc. What ever makes sense to the User Experience (UX) model. 3. I note that I concede it is the VIEW designer to choose initial pop-out attributes (if they 'care'). 3.1 My assertion is that the end-users (in all use cases) are the ultimate arbitrators. 3.2 Provide View or Window options to help people do their paid work, their community projet work, and have fun! Most comments seem to basically concur with the initial description. I concede that the person designing a View ought have the "first" say about the pop-out window's initial attributes (Always_On_Top or "standard"). That only makes sense if the view designer feels his/her window is so IMPORTANT that it must block all of the display(??). I'm not convinced there are many cases like that. To me, a "must have" is that the pop-out window can Minimize. It is a workspace window, why must it be non-Minimized? @Joshua j>> proper closure of this bug should include a description of what j>> the intended use is for detached views? This description would fill a large Olympic sized swimming pool, signifying nothing in my opinion. There are millions and millions of examples where and depending on what a designer, SA, tester, coder, QA person, Project Manager, BI consultant, etc, etc ~WANT~ to see and How they ~Want~ to see it. However I concede to radical views such as leaving the user in control as much as possible (so called, user-centric UX philosophy). 'Today' I am a developer (user) and I cannot SEE the dialogues and output console messages because the pop-out I dragged over 'there' can't be minimized or made 'Normal' (= NOT Always_On_Top). Tomorrow as a RAP or SCOUT end-user my pop-out window might hide some key stock-market tell and allow me to crash the whole global financial system because I didn't kill the pop-out I really (actually wanted to have aside on my screen), oops well we'll just blame the "computer system" again shall we? ~~ I won't do more. The key choice is: are the End-users in-power, or are they drones controlled by Eclipse? It is philosophical I know. Back in 1985~ish, the users were drones largely controlled by user interfaces driven by IBM 1400 series controllers. Almost 30 years later; people tend to shy away from that kind of facism (mostly). I don't consider this current (Kepler) behaviour to be a new feature; it is a lament on the user experience taking power from the "customers".
(In reply to comment #5) > Hello all. > > I am not pleased that the bug is now marked as: "Won't Fix". I'll address > the big points after the important points. This was closed as wontfix 6 years ago. Your diatribe is as misplaced as it is inappropriate in an OSS setting. That being said, I'll reopen so anyone that's interested can contribute. We have 2 weeks of Kepler M7 left to accept contributions, otherwise it would be early Luna. See http://wiki.eclipse.org/Platform_UI/How_to_Contribute PW
Hi I am running the latest version of Eclipse Kepler and I noticed that when I undock the console view I can't put it back in the editor. Also it always stays on top even though when I right click it it shows and Always on Top option which doesn't make much sense to me since it is always on top for me anyway. Is there a way to redock the item back into the editor? Also, is there a way to have it go behind so that it is not on top of all my other windows I may be using at the time when clicking on the eclipse app? Thanks for your help. Also, I am new to this bug site so forgive me if this is not the place to post this comment. Thanks, Ben Eclipse Standard/SDK Version: Kepler Release Build id: 20130614-0229
Benjamin, which platform are you running on ? Windows doesn't seem to provide a menu item for 'Always on Top'. IMO about the only thing that might be *possible* here is to at least provide the ability to minimize the DW.
I am running on ubuntu 13.04 3.8.0-26-generic #38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
It seems that Always On Top was the linux window system from a right click on the Console window once it was out of the Eclipse and on it's own. Basically once the Console window comes out of eclipse it stays on top by default. Also, is there a way to dock it back into the eclipse environment panes, once it is out, there is no way that I can see to get it back in the editor.
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. If you have further information on the current state of the bug, please add it. 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. If the bug is still relevant, please remove the stalebug whiteboard tag.
I see that the bug was first raised in 2006. It is now 2022 and after so many year we are now developing an multi platform application in the simulation domain for space based systems based on eclipse RCP that has alot of tabs/panes/windows. The usability is poor (unless you have a 42 inch screen) exactly because users cannot detach and then arrange the order of the window as they need so that working becomes a continuous moving windows around and scrolling. In addition on OSX if the detached window is moved to a secondary screen it disappear never to be found again (also the eclipse IDE behaves the same) so moving to an external screen would not work for our OSX users. Is there any hope that this is fixed ? to me it is not a design choice but from user perspective a functional bug.
