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.

Bug 19631 - [40cat] Option to not open output window after successful compilation
Summary: [40cat] Option to not open output window after successful compilation
Status: RESOLVED DUPLICATE of bug 58513
Alias: None
Product: platform
Classification: Unclassified
Component: Output Window (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Milos Kleint
URL:
Keywords: UI
: 61207 (view as bug list)
Depends on: 48811
Blocks: 22897
  Show dependency tree
 
Reported: 2002-01-21 11:35 UTC by Milan Kubec
Modified: 2008-12-23 14:33 UTC (History)
10 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
CompilerDisplayer.diff (1.51 KB, patch)
2002-04-10 08:24 UTC, akemr
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Kubec 2002-01-21 11:35:57 UTC
Output window could be customizable in a way that after succesfull compilation 
only message in status line would be printed and no output dumped to output 
window -> no OW openned. Just in case of error or warning (also customizable) 
the output window would be openned.
Comment 1 akemr 2002-02-13 09:51:56 UTC
OK, probably there should be option like "Open OW after succesfull
compilation?"

Then CompilerDisplayer should be modified to not print to OW (after
success) - it should be easy IMO

Do you think this option should be located in Output Window options
(or Compiler options)?
Comment 2 _ ttran 2002-03-20 17:04:30 UTC
Jano or someone from UI team, can you please answer Ales' question? 
Thanks
Comment 3 jrojcek 2002-03-21 08:33:30 UTC
Chris, you are working on Options system redesign to 3.4. Would you
answer Ales' question or should I look at it?
Comment 4 Chris Ledantec 2002-03-21 09:09:21 UTC
this looks like something for compiler options. i'll add it to the
redesign.
Comment 5 akemr 2002-04-10 08:24:07 UTC
Created attachment 5352 [details]
CompilerDisplayer.diff
Comment 6 akemr 2002-04-10 08:28:33 UTC
Svato,

it should be solved completely in compiler area. I prepared
diff for CompilerDisplayer, which will solve this issue,
after you'll add new option "dont open OW after success..."
into compiler options.

Thanks,
-Ales
Comment 7 Jiri Mzourek 2002-04-24 13:47:12 UTC
This behavior was introduced based on the result of usability tests.
So, if you really want to create this new option, it should be as
default in the current state. 
Comment 8 Chris Ledantec 2002-04-30 14:45:43 UTC
guys, what's the status. has an engineer from compilers been notified
that there is a fix for this? has it been integrated? 

i just want to close this bug.
Comment 9 Chris Ledantec 2002-04-30 15:03:45 UTC
after talking with Jirka i was reminded why the output window opens in
the first place -as a result of user data gather during a usability test.

when we have a different (better) way of comunicating status with the
user we can revisit this problem. for the time being this is as designed.

cL
Comment 10 Milan Kubec 2002-04-30 15:30:33 UTC
Are there any details about the usability tests. Are these users
advanced or complete beginners. I like editor open as large as
possible, so when I write source code I do not need output window at
all, then I use also compilation as syntax check during writing code.
So my basic loop is - write code - compile (90% cases compilation
without errors) - close output window with redundant meaningless
message - write code. So I would really appreciate to have a way how
to specify levels of verbosity to open output window. Something like: 
1) Open at any cases 
2) Open only for errors
3) Open for warning and errors
Every compiler has these levels of output verbosity, so why our output
window cannot have it too when displaying compilation status.

I'd really like to know something about the usability tests and I hope
that if there is some usability test for some UI feature that it
doesn't mean the feature couldn't be improved or extended. I don't
want to remove the feature I just want better usability (from my point
of view).

So, if there are no resources to implement it to MILESTONE_3, it's not
reason to drop it, it could be implemented later.
Comment 11 Jiri Mzourek 2002-04-30 15:42:01 UTC
Look on:
http://www.netbeans.org/issues/show_bug.cgi?id=7727

and the datails of the usability test are on:
http://ui.netbeans.org/usability/Nov_07_00/UserTestReportNBsite.html
Comment 12 Milan Kubec 2002-04-30 16:23:35 UTC
Thanks for links.

Taken from the usability study:

* Users tried to compile files and failed to notice the compilation
status displayed in the status bar. They compiled many times before
they realized that they had succeeded. Once they did locate the status
bar the message that appeared ("<filename> - finished") did not seem
very meaningful to them. Users (6 of 9) were never sure when to expect
feedback in the output window and when to expect it in the status bar.

This paragraph clearly indicates to me that participants were using
IDE for the first time in their lifes. But anyway. We are talking
about having more meaningfull message in output window so here are
examples of messages from status line and from output window from
fridays build after successfull compilation:

Status line: "Finished MemoryView"
Output window: "Finished MemoryView"

Exactly the same meaningless message. So my point is to *enable
advanced users* to avoid opening window (890x160 pix on my monitor)
with meaningless redundant messages. 
Comment 13 lleland 2002-05-01 23:39:54 UTC
I have just been pointed to this issue after asking the 
same question on the nbusers newsgroup, and I see another 
instance of a commonly encountered problem with development 
projects. This issue needs to be re-opened and placed at a 
higher priority as it introduces a negative impact on the 
most common usage cycle of this product. Hopefully this 
somewhat long-winded account can help clarify the issue.

First, these usability tests are clearly outdated since the 
GUI and the orientation documentation have undergone 
significant evolution since the date on the summary report. 
The report states that users had trouble locating 
compilation feedback but fails to investigate why. The 
answer is obvious and well-established from previous IDEs: 
The application status bar is on the top toolbar and not in 
the expected standard position at the bottom of the 
application window. This is not to state that the NetBean 
movable toolbar status line is a bad idea. On the contrary, 
a user-movable status line is a very good idea. However, 
the user is given no orientation or compilation specific 
documentation telling them about this new style of status 
line.

GUI users are used to starting a background function and 
encountering one of:
   * A pop-up modeless progress dialog.
   * Progress and result message on a standard application 
status bar at the bottom of the application window.
   * After reading an orientation document which clearly 
describes the manner in which this application reports the 
status of a background function, seeing clear and explicit 
messages on the progress and result of that function in 
that manner.

Second, the "A Tour of the IDE" document does not even 
mention the toolbar status line, nor does it explain the 
unexpected lack of an application status bar. The 
document "Compiling a Java Program" makes no mention of how 
compilation progress or results are delivered to the user. 
There is no reference documentation on this status line, 
how it is meant to be used, or how it can be configured. 
The user must either guess, visually scan the window for 
something that might deal with compilation, or ask someone 
else who might know. If they do see the status line message 
after a successful compilation, all they see is "Finished 
<filename>", which is about as unhelpful and cryptic as you 
can get.

Third, the unconfigurable compiler output pop-up window is 
a serious GUI problem. The cycle of "<edit>-<compile>-
<debug>" is the most commonly used cycle of IDE usage and, 
therefore, should be the most UI streamlined. It is also a 
well-established fact that vertical source code space is 
among the most valuable and should never be compromised 
without specific user configuration. In this case the user 
must close this compilation output window after every 
compilation to get their source code vertical space back. 
In the vernacular of developers: "This is half-frozen-
flounder-upside-the-head bad.".

The solution is simple in concept - the implementation 
depends on the state of your source.
   1. Continue to provide the movable toolbar status line 
but change all status message to be, and require that all 
new status message must be, clear and explicit. In this 
case the "Finished <filename" message would be changed 
to "Finished compiling <filename> - <status>". 
The "<status>" would be "Success" in a high-contrast green 
for successful compilation, and "Failed" in a high-contrast 
red for failure. The colors would help attract the 
attention of new users who have not read the proper 
orientation or compilation documentation, and they look 
snazzy.
   2. Update the documentation for functions that use the 
status line. For this example, "Compiling a Java Program" 
should have a third step in the compilation procedure that 
describes the use of the status line in displaying progress 
and result messages, and a list of the common message 
forms. There should be a link from this document to a 
detailed reference document about the movable toolbar 
status line. There should be a reference document for the 
compiler output window, how it is intended to be used, and 
how to configure it. "A Tour of the IDE" should be updated 
(actually it should be completely rewritten to be an actual 
tour of the GUI with pictures and links) to describe the 
movable toolbar status line, how it is intended to be used, 
and a link to the aforementioned reference.
   3. The display of the compiler output window should be 
configurable through both the options window and through a 
right-click context menu (properties). The display 
configuration should have the following application and 
project modes:
      * Display always.
      * Display only on failure. - default
      * Never display.
      This is further complicated by the fact that I have 
not found a way to configure if warnings constitute failure 
when compiling in the IDE. There should be a way to 
configure this.
      There should be an action for the menu/toolbar to 
display the compiler output window with the last progress 
and result message set of the last compilation performed.

This configuration provides the new user with the 
documentation they need to learn to look for the movable 
toolbar status line instead of the traditional application 
status bar. The explicit messages and result colors help 
catch their eye during and after compilation. The default 
compiler output window display configuration presents them 
with the full function of the compiler error display while 
still preserving the UI streamlining when there are no 
errors. The more advanced user is then capable of further 
streamlining the UI by not displaying the output window 
under other circumstances.

I realize this all seems somewhat long winded, but it is a 
typical example of the compounding effect of the number one 
and highest priority problem with NetBeans: The 
documentation. This whole problem was based on a poorly 
documented observation in a usability test where the reason 
for a problem was not investigated (eh, it happens). This 
causes a function to be poorly implemented. The problem is 
further compounded by the application documentation not 
addressing the method of compiler feedback. When the 
problem is pointed out by suffering users, they are told 
that the premise documentation proves that it is not a 
problem. This is bass-ackward thinking. The fact that users 
report this as a problem, supported with solid reasons (UI 
streamlining the most common IDE usage cycle), proves that 
the premise documentation is flawed and must be updated or 
revised.

I highly recommend that this problem be reopened and 
assigned a much higher priority given the fact that the 
most common usage cycle is affected. I also recommend that 
the pattern of flawed logic uncovered here be reviewed and 
looked for in other problems and processes with the 
development of this application. It is one of the most 
common patterns of development problem that occur in both 
commercial and open source projects. I've observed and 
dealt with it quite often over the years. I hope this helps 
people understand this issue and the more serious 
underlying causes.
Comment 14 Maya Venkatraman 2002-05-02 07:55:50 UTC
Milan - I was present at the sessions of this 
usability test and the participants were not novices to 
Java or to IDEs. 
Comment 15 Svata Dedic 2002-05-02 08:06:09 UTC
To me as a *daily user* of the IDE the usability study looks like an
attempt to create a "guide to be a piano master player" from observing
performance of people who claim they know how to play. Some of them
are poor, some of them master, and there's no guarantee that the
"masterness" is properly observed and recorded. They are playing it
their own way.
I don't care so much about the default setup and the starting parts of
the learning curve, but I need to be effective in my work. Extra
clicking or extra windows with no value added are not effective.
Note that this issue is not about "don't show" vs. "show", but "let it
be configurable and let's choose a default".
Comment 16 Tomas Hurka 2002-05-02 09:15:44 UTC
I don't understand what is the problem with this issue. Nobody wants
to remove current functionality, we only want to add _possibility_ to
configure it. So I don't see any reason why patch provided by Ales
Kemr cannot be applied.
Comment 17 Jiri Mzourek 2002-05-02 10:09:51 UTC
I don't have problem with applying of the patch. I just want to keep
current behavior as default.
Comment 18 Svata Dedic 2002-05-02 10:12:15 UTC
Good. Now would you please help me to find an appropriate place where
to put the option in both new-style options dialog and the property
sheet based Tools | Options.
Comment 19 Jan Lahoda 2002-05-02 10:18:03 UTC
Hi,
    I agree that one sentence (BTW, meaningless as Milan said) in
status bar can be easily overseen. But, I was developing with IDE when
the output window did not open itself, and I was quite satisfied.
I am sometimes working on 800x600 LCD display, and I have to say that
IDE needs tweaking on high level (changing properties on command line,
...) to make it usable on this resolution.
The current OW is (from this point of view) only another untweakable
place eater.
So, I see following as a good idea:
1. For now, provide an option to switch off useless opening of OW. 
(if it is possible do differentiate errors from warnings, the best way
would be Milan's three-layer proposal). The default state is not
important - so it can simply be the same as now.
2. For future, create better support for informing user that
compilation is proceeding and finished. For example small button on
the end of the status bar, that will be red while compiling and green
when the compilation is stopped.

I would propose, that the IDE should be designed so that it is usable
on resolution 800x600 without tweaking from command line.
(Of course, the IDE should be usable on higher resolution too.)
Comment 20 lleland 2002-05-02 17:27:31 UTC
I am greatly relieved to see that the re-opening of this 
issue has been accepted. As to the placement of the 
configurable options of the compilation output window:

Looking at the current options under "Options | IDE 
Configuration | Look And Feel", it strikes me that perhaps 
the terminology we're using is poorly chosen. The console 
output is already referred to as the "output window" 
(perhaps "Console Windows would be clearer and wiser here). 
Since this compilation progress and results window is quite 
literally a detailed listing of what is summarized in the 
status line, perhaps it would be clearer from a functional, 
organizational, and terminology viewpoint to refer to this 
window as a status detail window. Its configuration could 
then be included with any status line configuration options.

For example:
----------
A new "Options | IDE Configuration | Look And Feel | 
Status" entry that holds two children:
   1. "Toolbar Line"  holds font and display options for 
the toolbar status line.
   2. "Detail Window" holds font and display options for 
the pop-up status detail window.

Both of these entries hold a child for each function that 
uses status feedback to configure function specific Look 
And Feel options, like a "Compiler" entry that holds the 
default properties for any compiler such as the high-
contrast colors for the "Success" and "Failure" text in the 
compilation status line. Specific compilers that need more 
options can then create child nodes under this.

Each function that uses the status feedback resources could 
then have properties that configure how that function 
interacts with that resource. "Options | Building | 
Compiler Types | <compiler name>" could then have 
a "Display status pop-up" property that designates one of:
   "Always"
   "Only on failure" - default
   "Never"
As well a "Fails on" entry that defines what constitutes a 
failure:
   "Errors only"
   "Errors or warnings"
To make things more hierarchical, "Options | Building | 
Compiler Types" can have the same entries that would be the 
default used for any compiler type that does not defines 
their own overriding child nodes. In this way a specific 
compiler can define more failure types than just errors or 
warnings.
----------

This example decouples the Look And Feel options of the 
status feedback resources from the functional interaction 
properties for each function. This allows each function to 
use the status in the manner that make sense for that 
specific function. It also allows for the future expansion 
of more intelligent detail handling of one function without 
interfering with the operation of any other function.

Whaddya think? Do you see any problems with this?
Comment 21 David Simonek 2002-05-02 17:29:21 UTC
I'm voting for this issue, I'd also like to have an ability to specify
whether output should/shouldn't be opened after succesfull compilation.
Comment 22 Milan Kubec 2002-05-03 09:32:48 UTC
We're still talking only about successfull compilation, but note also
the case when everything is up to date and no compilation is
performed. Output window is also opened with message: "Nothing was
compiled, everything is up to date. Finished <classname>". Please
consider also this case. 
Comment 23 akemr 2002-05-03 10:16:53 UTC
My patch reflects also "Nothing was compiled, everything
is up to date..." case.

As you say in first comment to this RFE:
Just in case of error or warning the output window would be openned.
Comment 24 lleland 2002-05-03 10:18:53 UTC
In the solution I proposed, such messages would not be 
counted as a failure due to errors or warnings, and so 
would only pop-up a status detail window when the 
compiler "Display status pop-up" property was set 
to "Always". The other states would only display that kind 
of message in the status toolbar line. This was why the 
compiler result state is worded in terms of what is defined 
as "failure" and not "success" since there are other non-
success result states that would still be handled in the 
same manner as the success result state.
Comment 25 Chris Ledantec 2002-05-06 08:41:19 UTC
Options: i had this option included as part of Output Window options
then removed it when i saw that this bug hadn't been resolved. it can
go there for both the new options dialogs and the property sheet style
options. 

i think that's rather straight forward.
Comment 26 Svata Dedic 2002-05-06 08:53:34 UTC
Good. I think there will be some "general compiler options" in future
versions anyway (the ones now scattered in output, individual compiler
types, ...) - I suggest moving it there then when such category is
created.
Comment 27 akemr 2002-05-06 09:16:18 UTC
OK, reassigning back to me (because this option should now
be in OW options)
Comment 28 akemr 2002-05-06 14:28:21 UTC
Implemented in trunk.

There is new option (in Output Window options) -
Open after Successfull Compilation (default true = current state).

If it's set to false, compiler doesn't open OW after successfull
compilation.
Comment 29 Jan Zajicek 2002-05-09 10:30:01 UTC
verified in dev #20020509
Comment 30 Jesse Glick 2002-06-12 19:07:00 UTC
This feature broke for me in recent builds, incl. 3.4b1. I am using a
userdir only used for 3.4b1. I set the option to False, i.e. do not
open the window unless there are errors. But it is opened anyway.

E.g.:

0. Start 3.4b1 with fresh userdir. Close Welcome panel. Tools |
Options | ... | Output Window | Open After Successful Compilation ->
False.

1. Open examples.clock.ClockFrame (as text: "Edit").

2. Build | Build.

3. Output Window opens (note that its title is "Output Window [?]"
though the tab is named "Compiler"!). It displays only "Finished
ClockFrame.java" (as does the status bar).

When was this broken?
Comment 31 akemr 2002-06-13 08:32:33 UTC
Fixed in trunk.

Regression was caused by Ivan's integration on June 4th (OutputTabTerm
rev. 1.67). In this revision was (probably
by mistake) deleted some of my previous integrations.
Comment 32 Marian Mirilovic 2002-06-19 14:17:20 UTC
verified in [nb_dev](20020619)
Comment 33 _ mihmax 2002-11-05 08:39:38 UTC
Is this issue fixed in 3.4?
If yes, why is it not CLOSED?
Comment 34 Marian Mirilovic 2002-11-05 09:01:44 UTC
> Is this issue fixed in 3.4?
Yes it is. 

> If yes, why is it not CLOSED?
I understand that it should be closed, it should be done after release
fixed version of the IDE.
3.4 is released, I know. Why it isn't closed, maybe because it isn't
our habit to close these issues, but it must be.
Comment 35 lleland 2004-08-25 11:48:29 UTC
Well, this one's back. I've re-opened it for NetCat40.

In v4.0 beta 1, this configuration option has been removed. We can no
longer configure the Output window to not be opened/shown when there
is no build error. The status bar now only tells us that the build
ended, and not if any error occurred.

This configuration option should be put back in, and the status bar
should also state the result of the last action (failed or
successful). Actually, it would be better if this behavior were
disabled by default, but some think that there are those who will not
notice the status bar statement of success.
Comment 36 Jesse Glick 2004-08-25 19:32:06 UTC
No changes in this area planned for 4.0. The OW opens whenever a build
of some kind is initiated. If it is in sliding mode, you can easily
hide it with the Escape key.

I seem to recall there was a different behavior earlier in the 4.0 dev
cycle, but it was changed to this for some reason? Perhaps something
to do with the new OW impl?
Comment 37 _ tboudreau 2004-08-25 23:41:35 UTC
>I seem to recall there was a different behavior earlier in the 4.0 dev
>cycle, but it was changed to this for some reason? Perhaps something
>to do with the new OW impl?

Like what?  If you send output to the output window, you get an output window.  Don't 
want output? Don't write output.  I can't imagine what the output window could do for this 
- parse all the output and then show it only if "BUILD SUCCESSFUL" doesn't appear at the 
end?  Not the output window's job.

It would be relatively easy for the build process to cache the output of the build and only 
open an output window if it failed, dumping all of the cached data into it so the user could 
see what the problem is if there is a failure.  But the output window is just a stream you 
write stuff into.  The way to not make it be there is not to ask it to be there.  There's 
nothing that the output window can do for this - the solution is for the build process to 
avoid sending any data there until there is something worth drawing the user's attention 
to.
Comment 38 Jesse Glick 2004-08-26 00:10:13 UTC
Jo, but earlier in 4.0 it behaved differently nonetheless. I think the
difference was that if the OW were minimized (slid out) it would not
automatically open it. (But the OW would still be there, with the
correct contents, if you wanted to look at it - which is what is
wanted, and which would not be the case if the Ant module buffered
output.)

Probably you would want it to open automatically when a hyperlink is
produced.

Is there some way to produce this behavior with the new OW? I.e.
produce an output tab, and write content to it, and render that
correctly if the user shows the window, but do not force the window to
be displayed if it is not already? In other words, have
IOProvider.getIO not forcibly show the window, though be able to do so
via some other call? That is what is wanted, I think, and I seem to
recall that that is what the old OW provided (and the Ant module used,
successfully). Note that the Javadoc for InputOutput.select() says
"Ensure this pane is visible." which implies that it might not be if
you didn't call it. In fact in older revs of Ant's TargetExecutor.java
I have a *commented-out* call to io.select(), with a comment "disabled
since for Ant-based compilation it is usually annoying". If I recall
correctly, it stopped mattering under OW2 because the IO became
automatically "selected" whether or not you called this method.
Comment 39 lleland 2004-08-26 00:38:58 UTC
It is correct that what is desired is not the elimination of the
creation of and streaming to the Output windows build pane, but simply
not opening/showing it unless the build process returns an error. It
is required that, if the OW is configured to not open/show on success,
 that it still have that build output when the OW is manually
open/shown so that the Developer can browse any non-fatal messages.
You still create and stream, you just do not open/show until you get
an error return. The status bar would reflect that the build is
running, each major build step, and successful completion.

I have to strongly disagree with changing this issue to an RFE. Not
opening/showing the OW was a working process from 3.4 to 3.6. It was
aggressively fought for through this issue report. It has disappeared
in the 4.0 beta and creates the same situation as existed in the 3.4
Beta. The dropping of a once working process is a DEFECT and not a new
FEATURE request.

The excuse "you can easily hide it with the Escape key" is
unacceptable. The whole point of this Beta process is to validate the
functionality and streamline the UI. Requiring yet another keystroke
or mouse click every time a build is done is contrary to this process.
This UI is bloated with unnecessary keystrokes/clicks that slows down
the most common cycle of edit/build/debug.

Yes, this might seem picky, but I have to be the champion of a
streamlined UI for the most common Developer tasks, and the
edit/build/debug cycle is, by far, the most common task that coders
perform in NetBeans. When they perform it, they are usually debugging
a problem that makes them cranky and testy. Abusing them with extra
keystrokes/clicks, changing or occluding their visual layout without
permission, or requiring them to change back-and-forth from mouse to
keyboard is very counter-productive and usually results in soda and
water containers being thrown at the head of the Project Leader (me!).
Comment 40 Jesse Glick 2004-08-26 01:24:16 UTC
Whether you call it a feature or a defect, it was consciously dropped
as a requirement from 4.0 and cannot be considered for the 4.0
release, though it should certainly be considered for 4.1 or whatever
comes next.
Comment 41 lleland 2004-08-26 03:01:21 UTC
Considering the history of this issue, reasoning that supports pushing
it off until a later release needs to be seriously reviewed. This is a
VERY annoying behavior to the Developers who perform the most common
use cycle in NetBeans of edit/build/debug. It is exacerbated by the
fact that we've fought for it before, and it should have been included
in the functionality of the new OW for this release.

It's simple, obvious, well-reasoned, and caters to the most common and
influential block of users of NetBeans. I fail to understand why this
must always be such an issue. A configurable UI is an axiom of
NetBeans, not a grudging exception.
Comment 42 Jesse Glick 2004-08-26 05:44:12 UTC
Well I would rather implement it sooner than later but we are not free
to commit anything at any time. NB 4.0 is well past API and UI freeze,
and such a change probably requires some kind of change in the APIs
(at least a reinterpretation), a clear change in the UI / workflow
which affects documenters and testers, and the risk of introducing
unintentional regressions. The issue is the timing and the risk, not
the desirability of the change. Maybe someone with more authority on
that can comment further.
Comment 43 Petr Hrebejk 2004-08-26 13:53:20 UTC
After some consultations we decided to make it an enhancement for the
future versions. Things changed since the release this issue was
filled against. The window system is different now. When the user
makes the OW to be a sliding window it does not clutter the screen and
it only pops up when the IDE is building. 
However it should still be considered as desirable to implement for
example when improving the ant-OW integration as required by UI guys.

Ayway, I don't recommend to fix it for 4.0 and would rater wait for 4.1 
Comment 44 lleland 2004-08-27 03:49:01 UTC
As quoted above, I included both the tiled (opened) and sliding
(shown) window in the problem description. It does clutter the screen
(obscures the view of the file being edited) when it pops-up for no
good reason. It still requires either an extra keystroke (escape) or
mouse-click to close/hide it, cluttering the UI. In other words: it
DOES clutter the screen, and popping up when the IDE is building IS
the problem. Simply misquoting my original problem description is not
productive.

The formal purpose of a Beta process is to identify and fix problems
with functionality and useability. The UI cannot be "frozen" before
the Beta since half the purpose of the Beta is to refine the UI. Beta
is not just for easy patches, it is the endgame of the
design/implementation cycles and still requires both design and
implementation.

I realize that the decision is made, wrong though it may be. I'll look
for this in 4.1.
Comment 45 Milos Kleint 2004-11-18 15:30:13 UTC
i've integrated tabs flashing (issue 48811), so one option to
implement this could be to have the output flash a few times when
there's successful compilation. and open it when it failed. 
however the exact UI behaviour is still not clear to me.
Comment 46 _ tboudreau 2004-11-19 03:04:16 UTC
You should be able to test the flashing tabs code out (works with sliding windows as well), 
just by doing the flashing when the first line with an "important" listener is hit (that's 
actually more or less what I did to visually test the code).
Comment 47 Milos Kleint 2004-11-19 08:23:12 UTC
well,  for testing it's ok, but for real use in the IDE I'd rather
have a spec from the HIE guys.
There's way too many combinations of how the window should react to
important/non important outputs..
Comment 48 Milos Kleint 2005-07-21 06:41:33 UTC
*** Issue 61207 has been marked as a duplicate of this issue. ***
Comment 49 Jesse Glick 2005-12-15 17:17:25 UTC
See "Always Show Output" option in Ant Settings in 5.0's Options dialog. Doesn't
flash, just opens OW (w/o focus) if a warning or error appears or if input is
requested.

*** This issue has been marked as a duplicate of 58513 ***
Comment 50 Quality Engineering 2008-12-23 14:33:29 UTC
This issue had *6 votes* before move to platform component