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.
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.
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)?
Jano or someone from UI team, can you please answer Ales' question? Thanks
Chris, you are working on Options system redesign to 3.4. Would you answer Ales' question or should I look at it?
this looks like something for compiler options. i'll add it to the redesign.
Created attachment 5352 [details] CompilerDisplayer.diff
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
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.
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.
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
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.
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
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.
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.
Milan - I was present at the sessions of this usability test and the participants were not novices to Java or to IDEs.
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".
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.
I don't have problem with applying of the patch. I just want to keep current behavior as default.
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.
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.)
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?
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.
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.
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.
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.
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.
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.
OK, reassigning back to me (because this option should now be in OW options)
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.
verified in dev #20020509
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?
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.
verified in [nb_dev](20020619)
Is this issue fixed in 3.4? If yes, why is it not CLOSED?
> 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.
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.
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?
>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.
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.
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!).
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.
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.
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.
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
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.
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.
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).
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..
*** Issue 61207 has been marked as a duplicate of this issue. ***
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 ***
This issue had *6 votes* before move to platform component