Bugzilla – Full Text Bug Listing
| Summary: | [Jobs] Manual build in background doesn't give enough feedback | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Philipe Mulet <philippe_mulet> | ||||
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | erich_gamma, jeem, jerome_lanneluc, john.arthorne, n.a.edgar, sxenos | ||||
| Version: | 3.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 54748 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Philipe Mulet
*** Bug 52657 has been marked as a duplicate of this bug. *** Currently you get the progress window and the indicator moving. Is there a particular view you want feedback in? Bug 52477 details some of the problems with stale markers in the problems view - if that is the one you want updated we should move discussion to there in order to keep the information in one place. The indicator doesn't indicate that the build is in progress but that some background activity is occuring. The progress window is always closed for me. If it would open automaticaly during the build, then close automaticaly when the build is finished, that would be good for me. This bug is about a different problem than bug 52477. It is about feedback that the build is in progress. Same for me, the progress view is somewhat an advanced view, in case I do care about internal processes. For daily operations, I should not rely on this view to be available to figure basic actions. If that was the case, then the progress view should be made open by default, and brought to front anytime something relevant occurs... However, when problems are notified, then the problem view gains focus, and the progress view disappears (as usually these are stacked together). I'd rather get some visual cue that a build is occurring, and provide a way to surface the problem count evolution, maybe in the status bar (probably not the best take) ? If you double click on the indicator you will get the progress window back. In the latest integration build this window is much smaller and on top of the status area (we found that users missed it in the status area). So really it is problems view updating that is going to be the most help correct? There are several problems with using the progress window to know if the build is in progress: 1. When you double-click on the indicator, it opens in all windows, which looks really bad. 2. Double-clicking is not satisfactory as you need an extra step to know that the build is in progress. 3. If you have other jobs running, you don't see that the build is in progress. 1) This has been fixed 2) Doublinb clicking is only required if you turned off the indicator previously. If not it will come up for free. 3) This is why we took it out of the status line but admittedly we only show 2 jobs so point taken. I think improvements to the Problems View are the most interesting things we can do. Thanks for your input guys So you're not going to solve this problem because it is not interesting? Sorry Jerome I don't get your point. What I am trying to figure out is how to show you that a build is in progress in more places as the current places we show things are not suffecient for you. I give you a means via the floating window to show something is going on but I see your point that the feedback is sometimes hard to notice so I think some finer grained feedback is required. We don't want to go locking your workspace or throwing it in your face (thats why we moved it to the background in the first place) so we need to determine how to make the fact that a build is going on more obvious. The most obvious place is in the problems view as this is where you will look first to see that your changes are doing what you want. What about animating the build button while build is in progress ? I would go in the problem view to know if the last build produced problems, not to know if the build is in progress. And what if I have no new problems? Here is a scenario that is not currently handled: 1. Start with no problems (the problem view is empty) 2. Makes several changes that introduce errors and that are going to take more than 10 seconds to compile 3. Ctrl+B 4. Go to the problem view Observe: it is empty. So I'm happy and I start doing something else. 5. Wait 30 seconds Observe: the problem view now has problems I was happy after step 4 as I thought my changes didn't produce any problem but I was disapointed after step 5 as my assumption that the build was finished was wrong. So the point is: you have to show that the build is in progress, not only the result of the build. As Philippe said, animating the build button would show that the build is in progress. Phillipe: You mean the button on the toolbar at the top of the window? We were thinking more along the lines of the tabs and contents of the problems view as it is much bigger. Jerome: I agree completely. What I am advocating is showing an "in progress" state in the problems view so that you know it is not done yet. OK. That was not clear from your previous comments. Are you planing on bringing the Problem view to the front while the build is happening? If it stays underneath another view, then all these effort will be in vain. Yes - that would be a good idea (assuming you have the current bring to front option selected in the view) Not sure what this 'current bring to front' option is. Is it a new option in today's integration build? Animating the build button would actually make the most sense to me. In a similar fashion, I would expect in term that when synchronizing, the sync button would animate too (or think of search too), etc... Having dedicated views fighting to gain focus will end up confusing me completely, if I am synchronizing while building while searching... No it has always been there - it is the Open on new problems option. We can just reword it. The problem with animating toolbars is that too much animation will go on and just be a useless distraction. It is the same issue as the progess floating window - it shows that something is going on but not really what parts of thw workbench are affected. Note the current (I20040219) behavior of this option doesn't bring the Problem view to front if there are no new problems. So it is not just a matter of renaming... Not sure about animating... the problem with floating toolbars is that they were floating... taking more space, and hiding something. What I am suggesting should not consume more space, and allows each major action to inform about some progress (think of web explorers animations when busy). cc'ed Erich who may want to jump in the animating debate. Do you mean the debate is animating, or the debate is about animating the icon? <g> My two cents: icon animation is dangerous because it makes the UI look flashy and distracting. It could only work if the animation was very subtle and not distracting (like the save and print animations in MS Word). I do recommend disabling the build button during build... this has the benefit of giving immediate feedback when the button is pressed, and prevents the user from repeatedly clicking when they think the build isn't working. This is similar to the new search view that enables a cancel button while the search is running. animating indeed, some more animation thoughts * There a serious surprise when build is run in the background for the first time. You will press build multiple times until you learn that the build is taking place in the background. There should be some strong feedback to avoid this surprise and to avoid a bad OOBE. Suggestion: show a dialog that asks whether the build should be run in the background with an option to never show this dialog again (same as when switching perspectives after project creation). * build progress feedback - The most important information of a build is: is it done(see comment# 11)? and how many new problems/warnings are there. ->This information isn't easily visible anywhere. (the Problems view can be docked as a fast view and the shown on error toggle can be disabled) - building is a global activity and not tied to a particular view, i.e., it affects the tasks and problems view plus other views showing error ticks, e.g. the package explorer. ->Showing build progress in a particular view isn't a complete solution. ->Showing the progress by disabling a button is good but it isn't sufficient. - building is a central activity of an IDE. It is at a different level than jobs like "reconciling the CVS state" and "searching markers in the problems view". ->showing the build progress in the Progress view isn't sufficient. It is a distinct Job and deserves special feedback. How about a "global" segment in the status bar that is devoted to build information: - the segment would show some feedback that a a build is going on - when a build is finished the segment shows the number of errors/warnings. - the segment should also indicate whether auto build is on or off (this information is currently hidden in the preferences). Since John mentioned the new search view. We have found that showing progress by only enabling/disabling the stop button isn't sufficient. The plan is to leverage the view title text (once it is back). We will also look into whether "disabling" the items as is done in the synchronize view helps. However, since the view can be empty for a long time during a search this isn't sufficient. So we are also experimenting with a subtle animation. Against disabling the build button is the fact that when a build will take a long time, I may still perform a modification and want to build all over again. I imagine pressing the build button will cancel the ongoing build and start a fresh new one. Re comment #23 - you can't modify files during a build. If you try to save a file, you currently get the "busy" popup and from there it is possible to cancel the build. Re comment #22 - Some jobs are strongly linked to a view, in which case view-specific progress is best (search, junit, repository view). Tod is working on a general mechanism for indicating that a view is "busy" (via IWorkbenchSiteProgressService). The value of this general API is to make view-specific progress more consistent - if every view rolled their own progress indicator we'd end up with a mess. Since build is not strongly linked to a single view (many people including myself never open the problems view), it might be worth exploring a specific progress indicator for builds. Of all the suggestions, I like a small status line contribution the best. It would not have room for detail (such as problem count evolution), but would at least give a visual cue that a build is in progress. We explored showing all background progress in the status line, but it became far too cluttered. Showing progress in a controlled way just for builds might not be as bad (maybe hovering on it would show a tooltip with problem count evolution). Logged Bug 53327 [Jobs] Second manual build should optionally cancel the first for the multiple build problem. Bug 46974 [Tasks] Problems view should invalidate during builds deals with the problems specific to the problems view. Bug 53326 Pane colors to change for Jobs support is about the general support we are going to give to show this progress. Bug 53324 deals with the issue of adding a progress line to the status view and turning off the Floating window by default. I am going to leave this report open as we still need to investiage possibly animating the ToolItem for build while it is running too. *** Bug 53452 has been marked as a duplicate of this bug. *** New behavior still doesn't solve my original issue as some build occur with no progress still (no clue why), see attached screenshot where unless going verbose you get no clue as what is going on. Also the 20 chars box at the bottom right doesn't indicate much about what is going on. When double clicking on it, I often get a floating window in the way which is confusing me even more, and prevent me from seeing the box any longer. Created attachment 8306 [details]
Still no good progress in 20040302
You are seeing Bug 52031. Closed as the system build jobs have been sorted out As an extra note we are planning on doing the following in 3.0: https://bugs.eclipse.org/bugs/show_bug.cgi?id=55090 https://bugs.eclipse.org/bugs/show_bug.cgi?id=55162 https://bugs.eclipse.org/bugs/show_bug.cgi?id=54748 |