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.
When a new Output window is invoked programmatically during compilation process, then it should obtain focus and should react on ECS key. Then Output window will disappear after this ECS key-press.
I meant Escape key of course, not ECS :)
This is a pretty annoying usability problem, -> P2. Tim/Dafe: who of you are fixing this bug?
Well I'm not working on this issue now, but yes I agree it must be fixed in promo-D. I'd prefer if Tim could fix this, AFAIK work needs to be done in output code to react in right way. Unfortunately it's too late to introduce API changes, so I suggest: - solve issue by hack, create public method isSliding() in Output top component, that will decide based on in which AWT hierarchy it exists - create P2 task for promo-E to introduce something like isSliding() API in top component. We already have another use case - action that should select a node in explorer, but only if it is not sliding.
The main problem is this: - On new output, the output window should *open*, even if the user closed it before - By default requestVisible() does *not* open the output window - it just makes it the selected tab if it wasn't before. If it has been closed, nothing happens. Hence you need to call TopComponent.open() on it when a process starts writing new output. But open() doesn't just mean "give me a sliding button", it means "give me a sliding button and show me". Dafe, any way you know of to have the output window say "give me a sliding button but don't actually open me"? So how to solve this? Two ways: 1. We don't call open() when a process asks for an IO and starts writing. If the user has ever manually closed the output window, they will have to go to Window | Output to show it again - it will never open automatically (it will behave like the Execution window, where, once you manage to kill it, it will never bother you again). 2. Options: - We provide some API so that a TopComponent can know it is open but not "slid out" (we will need this anyway - focus behavior will be different) or - We provide some API by which a TopComponent can specify what policy should be used on calls to requestVisible() (whether to open it if not opened) or - We provide some API or some call i.e. openButDon'tMakeVisible() for the sliding situation, or some flag to open() or some other way to do it. I suppose we could do this with client properties for now - not pretty but would work, mostly (as long as you don't need such info from the same call sequence that ran the constructor, before it's returned and something has a chance to apply the client properties).
I think it's simpler for now - leave everything as is, just give output window focus if it's sliding, like Dusan suggested. Every time something is writing in output and output is sliding, in will show up with focus and users can watch it and/or press ESC to dismiss it. Quite satisfying for promo-D IMHO and in line with what HIE wants.
IMHO: running a build should always make the OW visible (not just create a button); but should only give it focus when in sliding mode (when it is easy to get rid of it, with the Escape button). The analogy to the Execution view doesn't convince me; output from a build process is much more important to see than the Execution view. If you are just compiling and it is successful, perhaps you don't care much to see the output, but you can just make OW sliding and press Escape once you see that everything worked and you don't care to look at it any more.
Okay, Dafe, how to detect sliding mode?
Ehm, it's hacking time :-) Two possibilities I can think of: 1) SlideBar will put property isSliding to non null to TopComponents that are inside edge bars, and you'll check this property. 2) Traverse your parent AWT and if you find LayeredPane, look into which layer you belong - if it's not default, you are on sliding layer. However this will work only if component is really showing, which may not be the case.
>Two possibilities I can think of: >1) SlideBar will put property isSliding to non null to TopComponents >that are inside edge bars, and you'll check this property. If anything, we will need to do it this way - when something first starts writing output, the output window may not even be created yet. So the client property needs to be set right after the component is constructed or it will sometimes come too late. Jesse, don't you have some code in the build system that finds the selected editor and sets focus back to it after starting to write output? I've written some code that sends focus to the selected tab; it logs that it has found a tab and set focus to it, but focus actually remains in the editor - something is interfering. There are some non-trivial problems when it comes to focusing the empty output window so ESC can be pressed. The main one being that TopComponent.requestFocus() is overridden to be a no-op. So not only is there nothing to set focus to, even if I wanted to send focus to an empty output window (and draw some focus marker), I can't access TopComponent.super.requestFocus() to do it. I also anticipate focus problems detecting whether the output window has been shown because the mouse was hovered versus via an action versus because a process started writing output. For some of these cases focus should go to the output window, for some it shouldn't. I'd suggest that for Promo D we: - Allow a client property that lets a component say "I can't be a sliding window" and set it on the output window For Promo E, we should think carefully about: - How do sliding windows interact with focus behavior - What notification API is needed to let a component know *how* it is being shown - there are quite a few ways to show a component now: - User clicks a tab - User hovers mouse over slide button - User clicks slide button - The component shows itself in response to some programmatic event - User invokes winsys action to show the component and craft the appropriate APIs to make it work. We might be able to put together some sort of hack for D, but I don't think this can be fixed well without rethinking some of TopComponent's API. For many components, what we have works fine, but the output window is a special case. At best we're going to have one or another variety of wrong focus behavior and a big pile of hacks.
"Jesse, don't you have some code in the build system that finds the selected editor and sets focus back to it after starting to write output?" - the Ant module I guess you mean. Not any more; I deleted this at your request when you were working on output2. "I'd suggest that for Promo D we allow a client property that lets a component say "I can't be a sliding window" and set it on the output window" - -1 from me, the OW is much more useful in sliding mode IMHO.
Any objections if I change TopComponent.requestFocus() to public void requestFocus() { if (isFocusable()) { super.requestFocus(); } } and similar for requestFocusInWindow()? Then I can at least have a prayer of giving focus to the output window with no contents. Since TopComponent sets focusable to false in its constructor, this will have no effect on any TC that doesn't explicitly call setFocusable(true) on itself.
Ccing Dusan so that he knows about focus problems with OW. However I admit I don't fully understand what is Tim talking about :-( reply to Tim: "I'd suggest that for Promo D we allow a client property that lets a component say "I can't be a sliding window" and set it on the output window": -100000 from me too, Jesse is right. request for Tim: I'd like to finally solve this like we hopefully agreed. I already implemented client property "isSliding" which is set to true when component is in auto-hide, so you can test it in OW and focus it. Although I agree we should re-think focus policy for output window (together with HIEs), I still think that focusing output when in sliding mode will be enough for pleasant use.
> -100000 from me too, Jesse is right I agree, it's not desirable. Anyway, I've got code to make it focus itself which should work if Boolean.TRUE.equals(getClientProperty("isSliding")). Main problem will probably be ensuring that it *doesn't* get focus if the user hovers the mouse to show it. So we're clear, the desired behavior is: - Something programmatically opens the output window - show it, don't give it focus - User choses the output window action - show it and give it focus - User presses the sliding button - show it and give it focus - User hovers the mouse over the sliding button - show it, don't give it focus Dafe, I assume I don't do anything special for these last two - one will call requestVisible, the other will call requestActive? I will add some kind of focus rectangle painting for the output window when empty, so it's possible to tell where focus is, and modify TopComponent so it is possible to give an empty TC focus.
Checking in TopComponent.java; /cvs/openide/src/org/openide/windows/TopComponent.java,v <-- TopComponent.java new revision: 1.129; previous revision: 1.128 done Processing log script arguments... Mailing the commit message to cvs@openide.netbeans.org (from tboudreau@netbeans. org) Checking in src/org/netbeans/core/output2/Controller.java; /cvs/core/output2/src/org/netbeans/core/output2/Controller.java,v <-- Controll er.java new revision: 1.6; previous revision: 1.5 done Checking in src/org/netbeans/core/output2/OutputWindow.java; /cvs/core/output2/src/org/netbeans/core/output2/OutputWindow.java,v <-- Output Window.java new revision: 1.4; previous revision: 1.3 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/core/output2/ui/AbstractOutputPane.java; /cvs/core/output2/src/org/netbeans/core/output2/ui/AbstractOutputPane.java,v <- - AbstractOutputPane.java new revision: 1.8; previous revision: 1.7 done Checking in src/org/netbeans/core/output2/ui/AbstractOutputWindow.java; /cvs/core/output2/src/org/netbeans/core/output2/ui/AbstractOutputWindow.java,v <-- AbstractOutputWindow.java new revision: 1.5; previous revision: 1.4 done Checking in src/org/netbeans/core/output2/ui/CloseButtonTabbedPane.java; /cvs/core/output2/src/org/netbeans/core/output2/ui/CloseButtonTabbedPane.java,v <-- CloseButtonTabbedPane.java new revision: 1.3; previous revision: 1.2 done Processing log script arguments... Mailing the commit message to cvs@core.netbeans.org (from tboudreau@netbeans.org )
seems to be ok in 4.2 dev 20050729. Verif.