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.
See UI spec for Filter button. Not clear yet what exact semantics should be. E.g. "display all messages at WARNING or ERROR level as well as messages from <java> tasks at INFO" ?
is the filter button supposed to filter out already printed stuff? I mean let's say the filter button is pressed after the whole build output was printed. Should the OW get cleared and reprint just the relevant messages? that is feasible, but requires extra bookkeeping on the ant side as the ow is not able to decipher what is important and what's not. it would probably mean ant writes the output down in file and then reparses and reprints? possibly slow/memory hungry. or is it meant to be a global setting for future lines coming from ant? will it be persisted across build sessions?
Making filter apply retroactively would be even harder than this issue would be already (API changes, ...) and possibly affect performance; so I would rather have it apply only to things printed after the button is toggled. Should of course be a persistent setting.
Making filter apply retroactively would be even harder than this issue would be already (API changes, ...) and possibly affect performance; so I would rather have it apply only to things printed after the button is toggled. Should of course be a persistent setting. Another possibility would be to discard the filter button idea and instead work on showing (1) program output in a separate window, (2) compilation errors in a unified tasklist window (well integrated with background compiler, editor hints, etc. etc.). Then the Ant output window would remain as a lower-level tool for analyzing build behavior but would probably not be opened by default during a build or run (could be initially in sliding mode and normally stay that way). This has been planned in some form or another since 4.0 but no one has had time to work on it so far.
Dear Colleagues, the motivation of Filter Button is to filter "not important" messages - > especially messages from ANT like init: deps-jar: compile: run: These messages are have less priority for the user, like Error messages from build or messages from Runnig application realize System.out.Println(); Of course, the filter could be complicated, but for this version is designed easy button -> ON (by default) means show only Error Warning (?) and System messages OFF - > show all messages like now. Read in http://ui.netbeans.org/docs/ui/outputwindow/OutputWindowUseCases.html -> Output Window Filters UseCases
Dear Josef, we are not discussing what is written in the spec but what is missing. 1. when filter is pressed to be ON, do we filter out also lines that were already printed? 2. what is the scope of the filter button? does it span all the currently running ant tasks? is it persistent across runs? 3. even if we filter out the unimportant lines from ant we still might get a mix o ant and user process messages (when Running the application). A possible solution to that is to completely separate the user program output into separate output tab.
AHOJ 1. when filter is pressed to be ON, do we filter out also lines that were already printed? NO 2. what is the scope of the filter button? does it span all the currently running ant tasks? Yes - The ANT messages could have "less" priority for standard NB User. And a lot of messages in the outputwindow are not transparent. is it persistent across runs? 3. even if we filter out the unimportant lines from ant we still might get a mix o ant and user process messages (when Running the application). A possible solution to that is to completely separate the user program output into separate output tab. I Understand, It could be hard to realize. I prefer to have only one console, because our users know that NB firstly checks the code and writes some error into the output and after that starts some application. To have more outputs I can't recommend. I am very happy for your energy to find final "best" solution. Thanks Josef
Between issue #41252 and CompileOnSave, this does not make sense any more.