Bug 37227

MDI or SDI? Why should focus go to another window when you close
something in Debugger Window? It is first time I hear about such
behaviour. What is exact scenario?

I assume you have focus in dbx console and you want to close some view
in Debugger Window right? And you expect that focus should stay in dbx
console right? It makes more sense. But as you click toolbar inside
Debugger Window to close/open any view it transfers focus to Debugger
Window. If I am right Debugger would have to fix this but I do not
know if it is possible at all. (Toolbar would have to be unfocusable
ie. no FOCUS_GAINED event would be generated when you click on it.)
Pls check and confirm or fix what I wrote.

Cc'ing Ivan, whom I know is planning some work on focus in Term in the
near future.  Questions: 

Is this with the old or new window system?

So, focus is in the output window.  How do you close/open these views?

If it is with the mouse, and you are clicking a toolbar button, I do
not think it's unreasonable that if you click in a different
window/logical component, that focus should not be transferred. 
Although I don't see any particular reason that toolbar buttons should
be focusable at all, and that would be a simple enough change.

On the other hand, if you're using a keyboard shortcut to open the
debugger view, then I agree, opening a component should not be
synonymous with shifting focus all the time - but it is a window
system issue, not an output window issue.

What *does* get focus after you open a debugger view?  
Is focus lost completely or is it somewhere in the opened view?

In any case, I'm not sure this is a bug - that is, typically when
someone opens a window, it's because they want to interact with it,
and moving focus there is the logical thing to do.  Conceivably there
might be views which really are "just for looking at" - and perhaps
the window system should provide some support for windows that
typically should not get focus when they are opened.

Anyway, more info is needed to properly evaluate this issue.

Correction, I garbled this sentence with too many negatives:

"If it is with the mouse, and you are clicking a toolbar button, I do
not think it's unreasonable that if you click in a different
window/logical component, that focus should not be transferred."

(the last "not" shouldn't be there)

Translation:  If you click in another window or logical component,
what should happen is that it or its default component should get
focus.  Is this a request to be able to click a toolbar button and
have focus not be changed to it or its container?  If so, I think that
violates some general UI principles.

Here is my scenario of how to produce the problem

0. bring up ide, load a debugged application, set bpt and execute...
1. click on the debugger window toolbar to toggle the local view
2. click on the output window dbx console tab
3. at the moment, I expect the mouse focus should be back in dbx 
   console, but what I see is the sqare cursor in dbx console 
   loss the blackness, and any keyboard action is ignored.

4. The only way to get the mouse focus back is to have mouse point 
   to non-ide area and come back to dbx console. I found this work
   around today (11-18-03)

I do not understand the following part: 
 
"but what I see is the sqare cursor in dbx console  
 loss the blackness, and any keyboard action is ignored." 
 
What square cursor?  The text caret or the mouse cursor? 
Please clarify what you mean by "loss the blackness". 
 
Also, is your window manager using focus-follows-mouse or click-to-focus?  
What window manager is it? 
 
Do you know where focus *is* after you click?  Is it possibly the tab of the 
tabbed pane (these are focusable in 1.4). 

Note this may be a duplicate of issue 24824. 

"but what I see is the sqare cursor in dbx console  
 loss the blackness, and any keyboard action is ignored." 
 
What square cursor?  The text caret or the mouse cursor? 
Please clarify what you mean by "loss the blackness".

  In dbx console, after dbx prompt (dbx-12345) you should see
  a square cursor, even if the mouse cursor is in somewhere else.
  Normally, it's solid black. 
  Under the scenario that I describled, this sqaure cursor turn into
  empty square.

 
Also, is your window manager using focus-follows-mouse or
click-to-focus?  
What window manager is it? 

  My window mangager is Sun desttop CDE dtwm, and I'm using 
  focus-follows-mouse
 
Do you know where focus *is* after you click?  Is it possibly the tab
of the 
tabbed pane (these are focusable in 1.4). 

  After I click on Output Window, the frame of Output window turn
  into blue, that make me believe the mouse focus is back to Output
  window, the only problem is that the sqaure cursor is not solid
  black. I was able to click on tabs in Output window and work fine
  in switching the tabs.

Created attachment 12226 [details]
Focus logging module

Okay.

First - I talked with my manager about this issue, because it was
filed last week.  It is not part of the list of issues which CDP core
agreed to fix for Rainier.  So I can't guarantee a solution to this in
that timeframe.  I'd like to try to help, and the fix may be simple,
so lets see what we can do.

I've attached a simple focus-logging module (you can find it on
netbeans.org in contrib/focusmodule - it's no work of art, but it does
what it's there for).

Install it in your IDE.  It will add two toolbar buttons that look
like mouse cursors.  First, click the one with a check mark.  It will
open a configuration dialog where you can define filters for what
events will be logged.  In the event name field (at the top), enter
the text "focusOwner".

Close the dialog, and click the other cursor-like button (with the
little dashes under it).  That will start focus logging to the console.

Wait a few seconds - the logging is set up to print some whitespace if
there is more than a few seconds delay between events, and that will
help me read your log.  Now reproduce your problem.  Then wait a few
seconds and click the logging toggle button again to turn off logging.

Attach the resulting log from this issue - and I should at least be
able to figure out what *is* getting focus.

Okay, I've fixed issue 24824 in the trunk - the output window will now
use a normal JSplitPane.  So if your problem was the same as that
issue, it may now be fixed in the trunk.  Backporting it to 3.5 will
be a little problematic, since the class I patched didn't exist in 3.5.

Nonetheless, I'll attach a copy of core-output.jar from the current
trunk including my patch.  Try dropping it into
$IDE_HOME/modules/autoload to overwrite your existing core-output.jar
and try it.  Then we'll at least know if your problem is the same as
issue 24824.  It *should* work but I make no guarantees - I can start
the rainier branch platform with it, but I don't have anything handy
there to generate some output to see if it works.

Created attachment 12227 [details]
Gzipped core-output module from current trunk.  Your mileage may vary, but we may be able to find out if your problem is the same one I fixed

Any further feedback on this issue?  It's still at the top of my list,
but without further input I can't do anything about it.

Please try the attached core-output.jar - just replace the one in your
rainier build's $NB_HOME/modules/autoload.  That will at least tell us
if the problem is the focus going to the splitter.

Removing RAINIER keyword - this issue was filed after the list of
issues to be fixed for rainier were agreed upon.

Dropping priority to P3.

Please duplicate the problem and press CTRL-SHIFT-BREAK - that will
print out the current focus owner to the console.

This issue is probably a duplicate of issue 24824 which is fixed in
the trunk.  Try the attached core-output.jar to confirm if the problem
still exists.

The attached core-output.jar is not compatible, causing following
problem:


Warning - could not install some modules:
        PVCS Command Line Support Profile - The module VCS Generic
Command-Line Support would also need to be installed.
        PVCS Command Line Support Profile - The module VCS Core would
also need to be installed.
        VCS Core - None of the modules providing the capability
org.openide.windows.IOProvider could be installed.
        Group of Files - None of the modules providing the capability
org.openide.compiler.CompilationEngine could be installed.
        Diff - The module Editor would also need to be installed.
        Debugger API - None of the modules providing the capability
org.openide.compiler.CompilationEngine could be installed.
        Forte X-Designer - The module C, C++, and Fortran Support
would also need to be installed.
        Sun One Studio 8 - The module Core - Output would also need to
be installed.
        Sun One Studio 8 - The module Editor would also need to be
installed.
        Sun One Studio 8 - The module User Utilities would also need
to be installed.
        Sun One Studio 8 - The module C, C++, and Fortran Support
would also need to be installed.
        Sun One Studio 8 - The module Debugger Core would also need to
be installed.
        Core - Output - The module IDE Core was requested in version
>= 1.15 but only 1.12.1 was found.
        Core - Output - The module Open APIs was requested in version
>= 4.11 but only 3.42.1 was found.
        Debugger Core - None of the modules providing the capability
org.openide.windows.IOProvider could be installed.
        Debugger Core - The module Debugger API would also need to be
installed.
        Debugger Core - None of the modules providing the capability
org.openide.execution.ExecutionEngine could be installed.
        Debugger Core - None of the modules providing the capability
org.openide.compiler.CompilationEngine could be installed.
        Core - Execution - None of the modules providing the
capability org.openide.windows.IOProvider could be installed.
        Editor - The module Debugger API would also need to be installed.
        dbx Debugger - The module Core - Output would also need to be
installed.
        dbx Debugger - The module Debugger API would also need to be
installed.
        dbx Debugger - The module C, C++, and Fortran Support would
also need to be installed.
        dbx Debugger - None of the modules providing the capability
org.openide.execution.ExecutionEngine could be installed.
        dbx Debugger - The module Debugger Core would also need to be
installed.
        ClearCase Command Line Support Profile - The module VCS
Generic Command-Line Support would also need to be installed.
        ClearCase Command Line Support Profile - The module VCS Core
would also need to be installed.
        C, C++, and Fortran Support - None of the modules providing
the capability org.openide.windows.IOProvider could be installed.
        C, C++, and Fortran Support - The module Debugger API would
also need to be installed.
        C, C++, and Fortran Support - The module Core - Execution
would also need to be installed.
        C, C++, and Fortran Support - None of the modules providing
the capability org.openide.execution.ExecutionEngine could be installed.
        C, C++, and Fortran Support - None of the modules providing
the capability org.openide.compiler.CompilationEngine could be installed.
        C, C++, and Fortran Support - The module Editor would also
need to be installed.
        CVS Command Line Support Profile - The module Diff would also
need to be installed.
        CVS Command Line Support Profile - The module VCS Generic
Command-Line Support would also need to be installed.
        CVS Command Line Support Profile - The module VCS Core would
also need to be installed.
        Performance Analyzer - The module C, C++, and Fortran Support
would also need to be installed.
        VCS Generic Command-Line Support - The module Diff would also
need to be installed.
        VCS Generic Command-Line Support - The module VCS Core would
also need to be installed.
        External Editor Support - The module Editor would also need to
be installed.
        External Editor Support - The module Debugger API would also
need to be installed.
        Built-in CVS Client - The module Diff would also need to be
installed.
        Built-in CVS Client - The module VCS Core would also need to
be installed.
        Welcome Screen - The module User Utilities would also need to
be installed.
        User Utilities - None of the modules providing the capability
org.openide.windows.IOProvider could be installed.

Okay.  Please try one of my suggestions for how to find out what
*does* get focus when you move the mouse back over the terminal
emulator.  Try CTRL-SHIFT-BREAK.

I moved mouse back to output window and click on output window,
the frame of outputwindow turn into solid blue (active), and then
I typed CTRL-SHIFT-BREAK, the stty did not show the current focus
owner until I moved mouse out of IDE territory, then the following
shown:


480> *** ShortcutAndMenuKeyEventProcessor: current focus owner =
org.openide.awt.ToolbarToggleButton[,102,6,24x24,layout=javax.swing.OverlayLayout,alignmentX=0.0,alignmentY=0.5,border=javax.swing.border.CompoundBorder@a53c0,flags=424,maximumSize=,minimumSize=,preferredSize=,defaultIcon=jar:file:/net/ryan1/export/jeanko/ws/dublin/nb_top/opt/netbeans/3.5R_build32/modules/autoload/debuggerCore.jar!/org/netbeans/modules/debugger/resources/watchesView/Watch.gif,disabledIcon=,disabledSelectedIcon=,margin=java.awt.Insets[top=2,left=1,bottom=0,right=1],paintBorder=false,paintFocus=true,pressedIcon=,rolloverEnabled=false,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=]

Hmm, that doesn't help too much - the toggle button has focus because
it was clicked.

Could you try the focus logger module?  And configure it to track both
focusOwner and permanentFocusOwner events?

OK, I'll try focus logger module, but how...?

Tools | Options | System | Modules - right click and choose Add New
Module from the menu.

In the file chooser, point it at uidiagnostics.jar (which you have
downloaded somewhere on your hard disk) and click OK.

The status bar should say "turning on modules", and a new toolbar will
appear with two icons.  The one with a checkmark is the settings. 
Click that one first, and in the dialog, follow the instructions I
gave above (see the post right after "created an attachment -
uidiagnostics.jar").

Then click the other toolbar button to start logging.

Reproduce the problem with logging on and attach the output to this issue.

Note:  If more than ten seconds go by between logged events, the
logger will write an extra CR to the output.  So to make it really
readable, you could move the mouse to the toolbar button, click it,
wait 10 seconds, then move it back to the output window.  Once that's
logged, click the logging toolbar button again to stop logging.

I make no claims the module is beautiful - particularly the
configuration dlg was done hastily - but it does work and is sometimes
useful for diagnosing focus problems.  The sources are in
contrib/focusmodule.

Here is the logging results:

The first logging is the one that focus does not go back to dbx console.
The second logging is the one with workaround: mouse focus leave
ide's territory and go back to dbx console, then the dbx console
can regain the mouse focus.


Turning on modules:
        org.netbeans.modules.uidiagnostics/1 [1.1 ${buildnumber}]
Event logging started at Fri Dec 05 18:49:41 PST 2003
Filters:
 - When  the property name matches "focusOwner" and the old or new
value changes 

--------------------------------------------------

1070679005624PROP: focusOwnerFROM:
org.openide.awt.Actions$ToolbarToggleButtonTO: null
1070679005633PROP: focusOwnerFROM: nullTO:
org.openide.awt.ToolbarToggleButton
-Event logging stopped at Fri Dec 05 18:50:21 PST 2003
Event logging started at Fri Dec 05 18:52:29 PST 2003
Filters:
 - When  the property name matches "focusOwner" and the old or new
value changes 

--------------------------------------------------

1070679152675PROP: focusOwnerFROM:
org.openide.awt.Actions$ToolbarToggleButtonTO: null
1070679152683PROP: focusOwnerFROM: nullTO:
org.openide.awt.ToolbarToggleButton
1070679157144PROP: focusOwnerFROM:
org.openide.awt.ToolbarToggleButtonTO: null
1070679158269PROP: focusOwnerFROM: nullTO:
org.openide.awt.ToolbarToggleButton
1070679158272PROP: focusOwnerFROM:
org.openide.awt.ToolbarToggleButtonTO: null
1070679158274PROP: focusOwnerFROM: nullTO:
org.netbeans.lib.terminalemulator.Screen
1070679162827PROP: focusOwnerFROM:
org.netbeans.lib.terminalemulator.ScreenTO: null
1070679165161PROP: focusOwnerFROM: nullTO:
org.netbeans.lib.terminalemulator.Screen
1070679166710PROP: focusOwnerFROM:
org.netbeans.lib.terminalemulator.ScreenTO: null
1070679166712PROP: focusOwnerFROM: nullTO:
org.openide.awt.Actions$ToolbarToggleButton
-Event logging stopped at Fri Dec 05 18:52:46 PST 2003

Well, the log shows focus going to TerminalEmulator.Screen...

Setting target milestone to future.

Resolving as fixed - the property sheet toolbar no longer exists in 3.6, so can't cause a 
problem; all other toolbar buttons in the IDE are no longer focusable.

Adding MERCURY keyword, raising to P2, and reopening. This bug will
be on the list of must-fix bugs for the Mercury release.

Is Mercury also to be based on NetBeans 3.5.1?  

If not, can we verify that this is really still an issue in the NetBeans 3.6 codebase?  To the 
best of my knowledge, in 3.6, all of the components involved in this issue no longer exist 
(no toolbars or toggle buttons in debugger views, rewritten window system, etc.); further 
the issue was focus finding its way to a toolbar button (which incidentally had just been 
clicked), and our toolbar buttons are no longer focusable.

the plan for Mercury and Vulcan is to use NB3.5 code

Okay.  Could we find some other ways to track these issues, if they are really requests for 
backports, not current problems in the codebase?

A couple reasons:
 - It makes it harder for developers to track what are ongoing problems and what are not, 
and confuses our own teams' metrics.  If we kept issues open until they were backported 
to previous versions, either all previous version branches would contain the current trunk's 
code, or all bugs would stay open permanently.

 - External customers *do* look at the number of open bugs against NetBeans when 
evaluating it (someone recently brought the count up on JavaLobby).  Having already fixed 
issues looking like they are still open makes things look worse than they really are, and is 
not good for the product.

Can not reproduce it any more,
the focus problem seems went away.

Okay, will anyone object if I close this issue?

verified

moving terminal emulator issues to terminalemulator component.
To see the correct version and target milestone of this issue look at Issue
Activity table.