Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. open eclipse: Java perspective 2. open a second window in a secon monitor: debug perspective 3. close the console view in the first window/monitor (you want more space for editing) 4. open the console view in the debug window/monitor 5. start an application which writes to the console BUG: 6. the console window keeps opening even in the java editing window More information:
Simone, which of the two windows is active when this happens?
sorry, steps to reproduce was written too fast, here it is again: 1. open eclipse: Java perspective (window 1) 2. open a second window in a secon monitor: java perspective but witha debug layout (window 2) 3. close the console view in the first window/monitor (you want more space for editing) 4. open the console view in the debug window/monitor 5. back to the java perspective, place a breakpoint 6. start the jUnit testcase in debug mode 7. the application does some text output BUG: the console window pops up 8. close the console in windows 1 9. the application hits the breakpoint (in window 1) 10. press step-over on a method which outputs to console (which is visible in window 2) BUG: 11. the console window keeps opening even in window 1 all in all basically what I want to do is to work with window1 and use the second window (monitor) to keep always visible: console, debug variables so, basically, to response to your question: the first window is active and the console was already visible in window 2
My suspicion is that the console is being opened in the currently active window. This makes sense most of the time since the framework doesn't know what the other open windows are being used for (or even that they're on a different monitor...). It also leads to interesting questions such as if I have 3 windows open and 2 are showing the console view which should be used?
My belief too is that the console is being opened in the currently active window. Even with 3 monitors and 3 windows the semantics can be defined to be clear: - if there is a _VISIBLE_ console window the output goes there and other consoles do not pop-up (otherwise) - if there is a minimized console in a _VISIBLE_ window pop-it up (otherwise) - pop-up a console in the _ACTIVE_ window the above rule would resolve also the problem that you mentioned The matter here is that _ACTIVE_ is a state which the application knows, on the contrary the _VISIBLE_ state is very tricky and strictly related to the OS. If I don't get it wrong I remember Win32 has an API to tell if a 'pixel' in a window is visible to the user or if it's somewhat obstructed. I wonder if: - there is an equivalent API on other platforms too - if SWT and an API for it
You could click on the toolbar item (or use the preference page) to not show the Console view when the program writes to standard output. If the view is visible in your second window, you will see the output; if the view is not active, its tab will be bold to tell you that there are changes in this view you might want to look at. I do agree that what you are asking for would be convenient, but I don't think it is important to implement.
Remy is now responsible for watching the [ViewMgmt] category.
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.
