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.
Run under 1.4 where scrollbars can take focus if ctrl-Tab is used. Get two panes into OW. Now bring focus into one of the OW terms and try moving the focus with the keybard using Cterl-Tab You will very quickly get lost as to where the focus is and more importantly it will not land on the Tab of the tabbed pane. There are several issues at work here. First JScrollBars can take focus via Ctrl-Tab but don't provide feedback. The way I"ve been checking things is by using the arrow keys and seeing if the scrollbars move. I've filed bug 4702175 against java on this. Second, OW actually has a SplitPane in it and normally it's "turned off". So as you Ctrl-Tab focus goes to vertical SB, horiz SB then it shifts to the other invisible Term of the splitpane and somehow never comes out! If you actually get an OW where the splitpane is visible you can track the focus between the two and it works. So I thought this was a swing bug and tried to come up with a simple testcase. Itturns out that swing normally won't let you completely 0 out a pane of a split pane, and even if you programmatically make the pane invisible the divideder is still there. So OW is doing something really unnatural with it's slit pane which Swings focus manager doesn't anticipate. This has actually been one of the reason I've been advocating getting rid of the splitpane and separated out and error windows (other reasons being resource usage and plain weirdness of it). But if you do want to keep it someone needs to figure whether the focus can be fixed in OW or isolate the problem so that a bug against Swing can be filed.
Ales, can you look at it, as split pane Ivan is talking about in inside output window. Thx.
After investigation, I found following solution: After setSplitType(SplittedPanel.NONE) I should somehow disable vertical and horizontal scrollbar of error pane term. (and enable them setEnable(true) for error pane separated - SplittedPanel.HORIZONTAL). I tried it and it works fine. However, I need some term API to enable/disable scrollbars. Can you e.g. overwrite term.setEnable to do it? I'm reassigning to Ivan to create such API. Then please reassign me back to call it in OutputTabTerm. Thanks.
Target milestone was changed from '3.4' to TBD.
doesn't seem we can fix it for 3.5 -> target = 4.0
Overrode setEnabled() for Term so it propagates enabledness to sub-components per Aleses request. It's a sensible thing to have in any case. However, I couldn't find the error and setEnabled() code in OW that Ales was talking about. So passing the bug on to Tim who's taken over Ales.
Alesi, any clues as to where this code was put? Was it committed?
AFAIK it was not commited and its probably lost now. I don't remember, it's too long time, sorry. I guess it should be something like: after setSplitType(SplittedPanel.NONE) call getTerm( false ).setEnabled( false ) and after setSplitType(SplittedPanel.HORIZONTAL) call getTerm( false ).setEnabled( true )
Question: Why create the split pane at all unless there is something to put in the other side? It should be possible to create and install it on demand, which would solve the problem. Also, it might be fixed by switching to a JSplitPane - I'm deprecating SplittedPanel for 4.0. Cc'ing Jan Rojcek - the way this issue is solved will probably depend on proposed changes to output window UI in the draft window system redesign doc.
Oh, I've been arguing for creating the error pane on demand for quite a long time, mainly for performance considerations. But this whole area is not very exciting, so no-one has been willing :-) In fact I"d go further and argue that separate out and err is not a good idea.
Well, it looks like the output window spec is changing for 4.0, so probably we can fix this in the process. Jano, any thoughts?
Well, I don't quite understand the original bug description. Is it still valid? How do I get two panes into OW?
To make the second pane become visible run a program that outputs to stderr. The discussion about "on demand" has to do with creating the Term object on demand (it isn't it is pre-created). The visibility of the second pane is still on demand.
Well, the solution should definitely involve creating the splitpane on demand - there's no reason to have a split pane which will not be used most of the time. Shouldn't be too hard to fix. That is, unless the HIE folks just want to get rid of the split pane and supply separate output tabs, or perhaps combine them by default. Unix and windows console applications do this routinely, so it would not be surprising, and probably 99% of the time either one or the other pane is going to be unused even if both are present. To preserve the possibility of separating stdin and stderr, we could allow separate redirection of them to different files - I suspect the splitting is one of those features which improves user perception by its removal.
I tried a simple program which I suppose prints a line to both the stdout and stderr. But only one tab is open inside the output window containing both lines. (I also experimented with stdin, but again, only one tab was shown). The program: public static void main(String[] args) { System.out.println("stdout"); System.err.println("stderr"); } However I found a problem when switching between two output tabs/views which are split inside the output window (e.g. two outputs of two different processes). It is not possible to move focus between them. I hope this is the bug you are referring to. This is the problem, and I think should be fixed so that Ctrl-Tab moves focus between two split terms. We can not remove splitting possibility as it is the feature of the current windowing system.
Cau Jano, try following code to see separeted output and error: InputOutput io = TopManager.getDefault().getIO ("tab_name"); io.setErrSeparated( true ); OutputWriter ow = io.getOut(); ow.println("output part"); OutputWriter ew = io.getErr(); ew.println("error part"); Ales
Now I am confused. Ales, your code is for module writers, right? How is the IDE user supposed to achieve splitting of panes inside one output tab?
Yes, it can be used by module writers (it was used this way in debugger). However also by IDE users - using Internal execution.
Fixed in trunk - now uses a JSplitPane instead of SplittedPanel, which presumably doesn't have these kinds of focus problems. May also fix issue 37227 (may be a duplicate of this); unfortunately, backporting the fix will be more difficult since OutputTabInner was created as part of the winsys rewrite. RCS file: /cvs/core/output/src/org/netbeans/core/output/OutputTabInner.java,v revision 1.3 date: 2003/11/19 22:04:12; author: tboudreau; state: Exp; lines: +71 -35 Fix for issue 24824, focus problems on splitter in SplittedPanel in OutputWindow replaced with JSplitPane. May also solve issue 37227.
This issue pertains mostly to the splitplane confusing things, but the scrollbars getting focus was muddying the waters. Workaround for java bug 4702175 suggests to make the scrollbars not be focusable, so made the horizontal and vertical scrollbars non focusable. The effect of this is Ctrl-Tab will not shift focus to the scrollbars.
verified