Community
Participate
Working Groups
Build ID: 3.4 It would be nice to provide feedback to users that a build which was explicitly invoked via a UI action provides feedback that it completed successfully. This dialog should not be displayed if a build is invoked as a result of an autobuild action - but only if a user clicks on an action that explicitly invokes a build (i.e. Project > Build). The dialog could then have a preference to disable displaying this dialog so that users who do not want the feedback to not get it. The reasoning behind this request is that some users of Eclipse-based products like to receive feedback that the action they explicitly invoked completed (either as a failure or successfully). Currently, only the failure case results in an error dialog but in the case of a successful build a user does not receive this feedback.
We discussed with Szymon and Kevin, but may require feedback from the community We believe the Project->build is the only action with no UI if the build is successful. We are not sure if the best is to list the success in the console by default or open a dialog with an option to not see the dialog again. I am adding McQ and John for their feedback.
Yes it's a bit odd especially if there's no work to do - you don't get any progress in the progress area, just nothing happens. One concern is that the UI doesn't get too perky in notifying of success. It might be enough to report in the console.
We used to reveal the problems view after a build. This is slightly more useful than a "build is complete" dialog because it displays useful information resulting from the build. This feature was removed because it stole the user's focus. See bug 45336 for details. There is also bug 263019 requesting that this be added back. I suggest collapsing this bug with 263019, and generalizing the title from " show a dialog/show problems view" to "show an affordance" when build is complete. The exact nature of the affordance to show is the sticking point.
Another thing I noticed while looking at this... we also used to set the Problems view title to be bold when problems/warnings changed as a result of a build. This doesn't occur any more. This was implemented in ProblemView, but the new implementation ProblemsView (note the 's') doesn't have this behaviour.
(In reply to comment #4) > Another thing I noticed while looking at this... we also used to set the > Problems view title to be bold when problems/warnings changed as a result of a > build. This doesn't occur any more. This was implemented in ProblemView, but > the new implementation ProblemsView (note the 's') doesn't have this behaviour. > I don't know whether this was a design choice or an oversight, but if there's no bug that captures the reasoning behind the change, you should enter one.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.