Could you clarify what is the desired behavior here?  I think if the compilation is 
successful, sending focus to the output window would be wrong - when compilation 
succeeds, there is nothing you can do with the keyboard in the output window anyway, 
and many people compile out of habit just to make sure they have not made an error.

If the compilation fails, arguably it is the right thing to set focus to the output window 
(though I recall another bug report requesting that focus *not* go to the output window).

If you ask me, then my opinion is that the output window should always
get focus. Let me explain why:

a) In full screen SDI mode, even if a compile is successful, and even
if one compiles because of the habit that you mention, one needs some
kind of feedback. There is no doubt about that. That feedback must
come automatically, at the end of the compilation process. The
feedback could be either a message dialog or the focus of the output
window or a message in the status bar of the editor window (if there
is one).

b) Older versions before the GUI changes change focus to output window
after compile in any case. It is not my intention to start a
re-evaluation of this de-facto standard.

AFAIK, in this issue, the missing focus ation does not depend on
whether the compile was successful or not.

Jano, could you evaluate this from HIE's perspective before we finalize what should 
happen?  IMO, changing the focus to the output window after a successful compile is just 
torturing people unnecessarily, but it may be the right thing after a failed compile.

Note also issue 39489 - a bug which complains that the output window *does* get 
focused, and requests changing that.

In SDI mode there are a number of scenarios where the lack of focus of
the output window is counter-productive, not just a matter of personal
preference.

Just as an example, suppose someone is in a full screen File Systems
window and wants to start debugging the project.

Then there is a compile error.

How shall this person know that the debugging session does not start
because there is a compile error?
Shall we all be forced to open the output window before starting a
debugging session?

On the other hand one could feel "tortured" (as someone said this and
I would not use this word) for being thrown into the output window
without necessity. Nobody wants to be forced to do something without
necessity.
But wait this is only half the story. The question is why one would
compile a file without necessity?

I could agree that doing so might be a habit. The question is whether
this habit is a good habit or a bad habit.

Then one has to ask what the correct policy is:

What is better style to reward good habits or bad habits?
And, when there is a choice, which habits could be afforded to be
penalised, the good habits or the bad habits?

I understand that the SDI mode is in principle the more advanced and
potentially more powerful and productive mode for users who like it.

The user only needs to know how to locate individual windows with the
window manager or shortcut keys. There is no need to worry about
screen real estate and how to arrange all the windows.

But the IDE needs a slightly more sophisticated approach to focusing
the windows. That puts a higher burden on the IDE. If the IDE does not
provide that support, then the advantages of the SDI mode are easily
offset.

> Then there is a compile error.

>How shall this person know that the debugging session does not start
>because there is a compile error?

>Shall we all be forced to open the output window before starting a
>debugging session?

I think we're conflating two things here - fronting behavior and focusing behavior.  The 
output window should definitely be fronted in SDI mode on compilation or beginning of 
output.  It should not necessarily steal keyboard focus from the editor after a successful 
compile - there's nothing to do with the keyboard there anyway.

Fronting it whenever there is new output, though, could prove maddening - imagine you 
are stepping through code that prints some output.  Every time you step through a new 
line that produces output, the output window would jump on top of the editor.  So I would 
propose the following as what should happen:
 - When an output is opened (new or reusing old tab), the output window should be 
fronted
 - No change to position or focus if there is simply more output written to it, for the above 
reasons
 - Focus change when there are errors?  Up to you, Jano.

Could this please be re-evaluated? Fronting and focusing on compile
error, at least when a single file is compiled, should be a basic
requirement - and it should be met.

This worked in previous versions. "Future" milestone hurts. This is 7
months old now.

fronting and focusing is the same IMHO. cannot have a non-fronted
window and have focus there at the same time.

I agree that this is an issue. The problem seems to be more with getting a feedback about 
the result of compilation than with not focusing the compiler window. Focusing the 
compiler window is just one solution, which was critisized in the past (that's why we 
changed it to not focus the window). Power users using SDI often know the shortcut keys 
so with knowing that there is an error it should be easy to switch into the compiler 
window, which is much better than switching there just to get to the compilation result.

Possible solution to consider:
* show the result of compilation in the editor status line (or in a new composed status line 
that would show up in Editor window in SDI)

Should be considered for the next release.

Thanks Jan.

Compilation for most means to request a compiler listing if there are
compiler errors. Why should users be asked to request this twice? Once
to start the compilation and then to request the listing?

Where and when did users complain that the compilation output was
shown when the compilation had errors?

>Compilation for most means to request a compiler listing if there are
>compiler errors.

I don't quite understand this - what do you need from the compiler that is not already 
displayed in the output window, and how do you go about getting it?  Are we talking about 
a native compiler here or something?  Certainly for Java when the compile fails, the 
compiler is stopped.  F-12 will take you to the first error and highlight it in the output 
window.  Please clarify - this isn't making sense to me.

If you just mean fronting the output window, that can certainly be done;  the only time it 
seems like it would be desirable to also focus it is if it is maximized (which is a pretty 
atypical usage pattern, AFAIK, but one that could be detected easily enough).

Tim, it's good that we have this discussion.

Yes, I mean only fronting the output window.

If, as you write, this can be done easily on detection of the window
maximized state, then that would be ideal.

I am using SDI mode with maximized windows except maybe property
sheets that I close as soon as I have used them. If you wand to
showcase the IDE software on a shrink-wrapped package, then this mode
of operation is probably not the best.

However maximized SDI mode certainly allows for most efficient
operation on displays of moderate screen size e.g. 17" with 800*600
pixels.

I wouldn't want to share the screen space of the editor or the output
window or the explorer with anything else. I know from our user
statistics that 100% of our users use our application full screen. And
I know from our web statistics that over 90% enter our public web
sites full screen, too. So I am not alone, and I like to view the
screens (client application) in design mode close to what the users
get at runtime. Not that atypical I think.

All this is at least one of the good reasons to use NetBeans and I
like it.

There are two issues discussing the output window opening/focusing behavior:

[40cat] Option to not open output window after successful compilation
http://www.netbeans.org/issues/show_bug.cgi?id=19631

OW shouldn't grab focus after unsuccessful compilation
http://www.netbeans.org/issues/show_bug.cgi?id=32492

From reading those issues it seems that two things are desirable:
* a good feedback that compilation finished
* an option to not open the output window after successful compilation

Okay.  I'd like to see us figure out if we can automatically do the right thing, rather  than 
needing to add an option.  Not sure if that's possible, but with careful thinking about it, it 
may be.  The desired behavior is distinct enough between MDI/SDI and OW maximized/
unmaximized that there are probably rules that do the Right Thing without requiring the 
user to have to discover a setting or decide what to do:

 - If SDI and Maximized and Compile Failed, front and focus OW
 - If SDI and Maximized and Compile Succeeded, don't show, front or focus OW
 - If SDI and not Maximized and Compile Failed, front but don't focus OW
 - If SDI and not Maximized and Compile Succeeded, don't show, front or focus OW (or 
maybe show it - debatable, but may be difficult to show but *not* front it)
 - If MDI... (same behavior as now)


Implementing this could be hacked, but probably will require a small bit of API to really do 
it right.  Right now, the window system doesn't expose whether it's in SDI or MDI mode; 
hack-wise, you can detect whether a window is maximized by calling 
getTopLevelAncestor() and getting the frame state and checking if it's the return value of 
WindowSystem.getMainWindow() - but it would be easy for this to break, so actually 
providing a programmatic way for the window system to get this info going to be more 
reliable.  We already use some client property hacks to do different OW behavior in sliding 
and non-sliding mode, which is due to get an API sometime in 4.1.

Adding Milos to cc, since I won't be working on core/openide post 4.1, and he'll probably 
end up with this.

Given that we have a history of changing/adding window system states and modes 
(workspaces gone, SDI gone, SDI back, sliding added, etc.) it might be best if we do this in 
some way that won't mean endlessly adding/deprecating methods in TopComponent.  
Suggest something like

StateInfo TopComponent.getStateInfo ();

public interface StateInfo {
   public static final String KEY_MODE = "mode";  //MDI/SDI
  //etc... you get the idea
   public Object get (String key);
}

Of course it could also just be this one method directly on TopComponent;  personally I 
prefer separating it, but it's up to you.

>Adding Milos to cc, since I won't be working on core/openide post 4.1, and he'll probably 
>end up with this.

post 4.1 -> post 4.0

Would it be possible to create something that helps SDI users when 4.1
comes out? I see very elaborate suggested solutions and I appreciate
them. Maybe some kind of compromise is possible on re-evaluation?

Please also consider issue 50522. The flow between source code window
and output window, broken as it is, makes the IDE look very stupid in
SDI mode.

Okay, I have committed an expedient fix that should make the behavior considerably 
better in SDI mode.  Reopen this issue if not satisfied.  What's changed:

If in SDI mode (if outputTab.getTopLevelAncestor() != 
WindowManager.getDefault().getMainWindow()), when an error line (hyperlink) is printed to 
the output window, it will become active/fronted/take focus.  No change in MDI mode.

Globally (SDI or MDI), if you press Escape when the editor is focused, it will send focus 
back to the editor (this isn't a bad idea for any component that can programmatically be 
sent focus - we might consider doing this globally for all non-editor views - works nicely 
already in Navigator as well).

Milos, sorry to be jumping in - it seemed like I could save everybody time by just going 
ahead and committing a reasonable fix.

Bernard, does this satisfy you?  True, the output window won't be fronted unless there's an 
error, but the fact of doing a compile and not seeing the output window fronted is enough 
to know the compile was successful.  Hope this helps things, anyway.  I'm marking the 
issue as fixed, but reopen if you don't think this is good enough.

Checking in src/org/netbeans/core/output2/Controller.java;
/cvs/core/output2/src/org/netbeans/core/output2/Controller.java,v  <--  Controller.java
new revision: 1.30; previous revision: 1.29
done

Tim,
Thanks for being accomodating.
Although I still feel that the output window should be fronted in full
screen SDI mode, I will give this fix a try for a while.
Maybe tit changes my expectations over time.
Thanks for the Esc key info. Actually this supports my current view
more than my own arguments because it is so easy to get back grom the
output to the editor with the Esc key.

In current version (Build 200507110943) the compilation status is printed in
status line (if compilation was finished or failed), when the compilation is
failed the output get focus, it doesn't matter the output is already opened or
not. But in case the compilation is finished and output is already opened the
focusing stays in editor, but when the output is closed, the output is focused
after compilation. I think, this behaviour shouldn't depend on whether the
output is already opened or not. Win 2000, JDK 1.6.0-ea 

*** Issue 39489 has been marked as a duplicate of this issue. ***

Too late for NB5.0, please reevaluate.

SDI is no longer supported.