Bug 24824 - Focus problems with splitpane in OW
Focus problems with splitpane in OW
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Window System
3.x
All All
: P3 (vote)
: 3.x
Assigned To: _ tboudreau
issues@platform
: A11Y, FOCUS
Depends on: 28297
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-15 01:35 UTC by ivan
Modified: 2008-12-22 19:38 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ivan 2002-06-15 01:35:50 UTC
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.
Comment 1 David Simonek 2002-06-27 15:15:59 UTC
Ales, can you look at it, as split pane Ivan is talking about in
inside output window. Thx. 
Comment 2 akemr 2002-06-28 10:11:57 UTC
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.
Comment 3 Marek Grummich 2002-07-22 08:31:27 UTC
Target milestone was changed from '3.4' to TBD.
Comment 4 Marek Grummich 2002-07-22 08:37:19 UTC
Target milestone was changed from '3.4' to TBD.
Comment 5 Marek Grummich 2002-07-22 08:50:36 UTC
Target milestone was changed from '3.4' to TBD.
Comment 6 Marek Grummich 2002-07-22 08:56:41 UTC
Target milestone was changed from '3.4' to TBD.
Comment 7 Marek Grummich 2002-07-22 08:58:53 UTC
Target milestone was changed from '3.4' to TBD.
Comment 8 Marek Grummich 2002-07-22 09:02:02 UTC
Target milestone was changed from '3.4' to TBD.
Comment 9 _ ttran 2003-02-28 08:27:43 UTC
doesn't seem we can fix it for 3.5 -> target = 4.0
Comment 10 ivan 2003-03-27 22:21:25 UTC
        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.
Comment 11 _ tboudreau 2003-03-28 08:49:36 UTC
Alesi, any clues as to where this code was put?  Was it committed?
Comment 12 akemr 2003-03-28 09:20:51 UTC
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 )
Comment 13 _ tboudreau 2003-03-28 11:36:09 UTC
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.
Comment 14 ivan 2003-03-28 21:55:32 UTC
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.
Comment 15 _ tboudreau 2003-05-21 23:02:59 UTC
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?
Comment 16 jrojcek 2003-06-11 13:49:14 UTC
Well, I don't quite understand the original bug description. Is it
still valid? How do I get two panes into OW?
Comment 17 ivan 2003-06-12 07:04:23 UTC
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.


Comment 18 _ tboudreau 2003-06-12 09:29:44 UTC
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.
Comment 19 jrojcek 2003-06-12 10:25:12 UTC
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.
Comment 20 akemr 2003-06-12 11:14:13 UTC
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
Comment 21 jrojcek 2003-06-12 12:12:11 UTC
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?
Comment 22 akemr 2003-06-12 13:51:50 UTC
Yes, it can be used by module writers (it was used this 
way in debugger). However also by IDE users - using 
Internal execution.
Comment 23 _ tboudreau 2003-11-19 22:23:38 UTC
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.
Comment 24 ivan 2003-12-17 00:05:24 UTC
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.
Comment 25 Marian Mirilovic 2004-08-16 15:23:35 UTC
verified


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo