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.
Summary: | Focus problems with splitpane in OW | ||
---|---|---|---|
Product: | platform | Reporter: | ivan <ivan> |
Component: | Window System | Assignee: | _ tboudreau <tboudreau> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | akemr, jrojcek |
Priority: | P3 | Keywords: | A11Y, FOCUS |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 28297 | ||
Bug Blocks: |
Description
ivan
2002-06-15 01:35:50 UTC
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. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. Target milestone was changed from '3.4' to TBD. 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 |