This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Does this make sense to others? I just figure: - If I have no compilation errors, I don't want my focus stolen by the output window. I want to keep on doing whatever I was doing before. - If I do have compilation errors, I don't very well need the output window to have focus because I can use F12 to jump to errors. Does anyone see a reason for grabing focus? Maybe I'm missing something..
Rainier blitz testing showed that this behaviour confuses users, because the color of selected object is not changed (in the Explorer that lost the focus). So users think that they can repeat Build or Execute action, and they do not understand why these actions are disabled. They do not expect that ourput window can grab the focus. Nikolay.Molchanov@Eng.Sun.COM
There is already a option to switch off opening OW after succesful compilation Options->IDE Configuration->Look&Feel->Output Window >> Open after successful compilation. It applies to focus grabing too. Only one remaining issue is if the OW should grab focus after unsuccesful compilation. I think that it makes sense to show errors to user and switch to the window w/ errors... But it could be in Options too... Depends on HIE(assigning Jano).
As was established in a separate I issue: - Netbeans should never grab focus away from the user. If it wishes to get his attention, it should make the relevant area stand out (highlight) or flash or something, but never steal away focus. - In case of an error, what's the point of moving the user focus to the output window? It's not as if users can do anything more when their focus is at the output window that they couldn't do before. Users can always push F12 to iterate through the error list. In fact, I don't believe there is any other way to iterate the list by keyboard; so why shift the focus? - The behavior of not stealing focus should not be optional; it should be default.
it's not clear to me what this request is about. Most of the behavior is configurable by the user. Some users prefer it this way, some the other way. So what is the exact request from Rainier team?
From Rainier's perspective this is an unexpected focus change. In recent usability testing I think 8 out of 9 testers had trouble understanding why build targets became disabled, even though they could see the Makefile was still selected. The answer was that the OW window had focus so the fact that the selected Makefile in the Filesystems tab wasn't really selected (although the selection highlight was still there).
Actually now Output Window is grabbing focus but TopComponent(s) inside Output Window. There are 2 things (please correct me if I am wrong). I tested this on Rainier. 1.First there is no Java compile like in Netbeans. There is tab named 'make' so code from OutputTabTerm: if (OutputTabTerm.this.equals(compiler)) requestVisible(); else requestFocus(); which handles compiler (Java compiling) tab does not work here. Special handling of compiler tab means that compiler tab does not grab focus when something is written to it compiler tab is only set visible ie. selected in Output Window without changing focused component in IDE. This could be solved by handling all tabs as compiler tab (not sure if it would not break something else eg behavior during debugging). 2.Second component in Output Window is Execution view which is opened as make task is started. Execution view also grabs focus. The only way I see to avoid this is not to open Execution view automaticaly. Please comment above if I am right or not.
Marek, I don't see why the Execution Window should *ever* grab focus. The only time users interact with it is when terminating applications and they never do that by keyboard anyway. This should be a passive window.
Marek suggests that this problem (#1) could be fixed if all tabs were treated as if they were a compiler tab but mentioned it could also break something else. I agree with both the suggestion and warning. So what to do for Rainier? Could you add some focus policy methods to OutputTabTerm so the tab creator could choose if a tab should get focus on output? That would let the compiler keep the same behavior and let the make tabs (there can be more than one) get the same behavior. It also allows other tabs (including our Debugger Console tab) to keep the same policy (grab focus) or change if that isn't the best choice. This seems safer than arbitrarily making all tabs requestVisible() rather than requestFocus(). What do you think? As for #2, I agree with Gili that the Execution Window shouldn't ever grab focus. However, I don't agree with Marek that the Execution view shouldn't be opened automatically. As Gili pointed out, its the only (semi-)obvious way a user can stop a make.
> Could you add some focus policy methods to OutputTabTerm so the tab > > creator could choose if a tab should get focus on output? I am afraid not because it would mean API change. (org.openide.windows.InputOutput). > As for #2, I agree with Gili that the Execution Window shouldn't > ever grab focus. It is how current winsys API works: When TopComponent is opened it is also activated ie. it gets focus. (So the only way I see to avoid this is to stop opening it automatically.) To Gili: In NB 3.5 it works fine for compilation regardless compilation was successfull or not. (The only problem is when compilation is invoked for the first time ie. compiler tab is opened it is activated but it is how TopComponent.open() works as I said above.)
I checked current Output API with Yarda and we found InputOutput.setFocusTaken()/isFocusTaken(). This is called from client code (mostly set to true) but it is not used at all in curent implementation in OutputTabTerm. So there is one possible solution to use this to control behavior of select(): If setFocusTaken is set to false only select given tab but do not set focus to it. By this way we would achieve desired behaviour but also API javadoc update would be necessary and change in client code (cpp module in this case - first setFocusTaken(false) must be called then select()) and change in OutputTabTerm.select() implementation. Second possible solution would be to set select focus policy (do not use current setFocusTaken()) when getting InputOutput instance from IOProvider: IOProvider.getIO(String name, boolean newIO, boolean requestFocusWhenSelected) But it is only one half of solution. Still there is Output Window focused when Execution view is opened or output tab is opened (for example when make is invoked for the first time -> new tab is added to Output Window). It is behaviour of winsys by design and cannot be changed. As I said problem with Execution view could be solved by not openign it automaticaly every time process is started.
Adding Ivan and Thomas to interest list since this fix affects both dbxgui and Thomas' branding module. Please take a look at Marek's 2 comments from Nov 11 wrt OW tabs.
Is there any decision how to fix this issue?
I should point out that this issue also affects building with Ant and so may not be limited to Rainier at all. *Currently* the Ant module asks that focus be given to the output tab when running a target - select() and setFocusTaken(true). However if Ant usage is to be more widespread in the IDE, this may become a UI problem, since you are often running a quick target while working in the editor and don't want to switch focus. Better would be if upon starting an Ant script - 1. The output tab is opened if it was not before. 2. If needed, it is brought to the front of other output tabs. 3. If needed, the output window is opened and/or fronted. 4. But the focus and selected window remains where it is whenever possible. I think a "poor man's solution" would be that the code which starts the script (in this case, TargetExecutor) would first find the selected window (and focus owner too? maybe not necessary); then open the output window (giving it focus and everything); then reset the selected window, unless that would hide the output window. If the documents window is maximized, e.g., then (as with Compile action currently) it should stay maximized and you should see nothing except the status bar saying that the script has been started, and later that it either finished successfully or failed. You can use F12 to jump to any errors reported (they will appear in the status bar) - you don't really need to look at the output window at all in many cases. I am happily using this style right now in a NB dev build with compile and unit-test targets: using Indirect Ant Compilation, I can navigate to a unit test in the maximized documents area, press F9, and see (in a second or two) whether it passed by looking at the status bar. If not, F12 jumps to the line with the failed assertion. More details are visible as needed using Shift-ESCAPE. Nice. Note that using Indirect Ant Compilation triggers use of the "official" Compiler output tab since it goes through the compilation engine, so this behaves differently in terms of focus than running an arbitrary Ant target (e.g. from the Explorer or a menu shortcut).
Jesse I strongly suggest to file new issue for new winsys. There is different behaviour in new winsys: Opening view does NOT transfer focus to it. In old winsys when view (TopComponent) is opened it is also focused (or at least requestFocus() is called).
You're right that's it different in winsys2. The new window doesn't grab focus. However the old window loses it (while staying selected)! Neat. I will file a bug. Sorry for the distraction.
Fixes are committed to release35 branch: core/output/src/org/netbeans/core/output/OutputTabTerm.java r.1.5.2.2.10.1 core/src/org/netbeans/core/windows/frames/Attic/MultiTabbedContainerImpl.java r.1.57.2.1.16.1 core/src/org/netbeans/core/windows/frames/Attic/SplitContainerImpl.java r.1.104.30.1
One more fix in OutputTabTerm.setOutputVisible: Checking in OutputTabTerm.java; /cvs/core/output/src/org/netbeans/core/output/OutputTabTerm.java,v <-- OutputTabTerm.java new revision: 1.5.2.2.10.2; previous revision: 1.5.2.2.10.1 done Changes: 1.Do not call requestFocus from OutputTabTerm.select, and OutputTabTerm.setInputVisible and OutputTabTerm.setOutputVisible. 2.Do not activate mode/component when component is added to container eg.TopComponent.open().
Marek, once the issue is fixed please set the target milestone accordingly. Also don't forget to port it forward to the CVS trunk, even though it's completely new windowing system there. Or at least file a separate issue for the trunk version
Should be fixed. Please reopen if you find any other way how Output window is activated.