Community
Participate
Working Groups
Maybe it is just me but i really dont like menu items that are in the menu that i press and then nothing happens. Ok a little thing in the right left corner tells me that something is started but that is not really visible. Now i always have hmm does it do something or not.. So i think what should happen is that the progress view should be set to front if already in the perspective or added to the perspective. So that a user gets the notion that something is changed/happened and something is working. Maybe it is because i have "always run in background" selected. But i do want that, except when it is really a user triggered menu action. Maybe you could always popup the checking for updates box, and be able to push that to the back no matter what that boolean says? P.S. why is bugzilla component list tells me: Update (deprecated -> use RT>Equinox>p2) But where do i choose that? Just select Runtime??
(In reply to comment #0) ... > Maybe it is because i have "always run in background" selected. But i do want > that, except when it is really a user triggered menu action. Yes, we honor the platform preference. The preference applies to background jobs whether the user triggered them or not. There are other menu items in Eclipse that operate this way (such as CVS Team->Sychronize...) although in that case you typically have a view up that is also changing in some way. It would be a fair bit of work to replace the platform jobs progress monitor for just this case. We could consider a duplicate monitor, but I think there are as many users who would then write a bug telling us to honor the platform preference. Maybe the very first time this happens we could put up a notification dialog informing the user that check for updates is running in the background with a [ ] Don't tell me again checkbox... I don't see us doing anything on this unless we get similar complaints or someone contributes a patch/idea.
if it was me you dont have to go around it or something like that just bring the progress view to front would already visually make it clear that something is happening. Because the current way is in my eyes bad interface design. If i press a menu item i expect that something happens, that i get feedback, that i see something progressing. And with the update i now now where to look in the right little corner but thats not really visible at all. The best way in my eyes would be that the menu button would start the update action just as it does now (so in the background) but it would always show a dialog that it is started. And that dialog has a cancel button and an ok or go to background button.. Problem is that you shouldnt show such a dialog if the show in background preference is false..
For example Firefox or Thunderbird/shredder those have the same kind of menu itme "check for updates". But they really show a dialog. Thats what i expect to happen.
This sounds like a general platform UI request to me. The entire "Run in background" preference only applies to jobs explicitly triggered by end user action. This is why a dialog is shown by default for this kind of job, because a less experienced user would find it confusing if we didn't. If a user has selected "run in background" then p2 behaves just like any other long running job triggered by the user (progress animation in status line only). Do you want the progress view brought to front for all user-triggered jobs, or just for the "check for updates" job? For UI consistency I would argue against treating this one job differently from others.
The other thing to keep in mind is that a product/app can set their own ProgressProvider on the job manager. In some configurations, we may not have a progress view, so having application code that assumed the progress view could come to the front may not always work. I agree with John that solving this generically is a platform UI issue. The only thing that might differentiate the "Check for Updates" case from others is that there is no associated view in which to provide other feedback, so the problem seems worse in this case.
then the question is what is a user triggered action? For example if i press CTRL-S in a dialog eclipse starts compiling in the background. That is what i expect to happen and should stay in the background But for example in the synchronize view, when i press the synchronize button. I see that the label of the view tab does get italic and again i see something in the progress view. But also that one i think is a bit wrong. The view should really say inside that specific synchronization that it is syncing this one. But that is more a CVS or an SVN thing to do i guess. Because if i press sync in syncronize set A and then i go to B and back to A where can i see that it already did something? You now see a spinning cursor of all of them, which doesnt really make much sense to me. What does a CVS sync of 1 project have to do with an SVN sync of another project? So i guess there are more places where the feedback could improve a bit.
CTRL-S in a editor ofcourse (instead of dialog..)
I think we can move this to platform UI. Here's my attempt to summarize the issue. Johan, please add/correct as needed. - The "always run in background" preference controls whether the jobs progress dialog is shown for a user-initiated background operation. - If this preference is on, the only affordance that something is happening is in the progress area in the status bar. Problem: A user may have turned on this preference because they frequently perform a particular background operation. Then they go to try a different operation. Since the user has no idea (and shouldn't have to) how any particular operation is implemented, they don't even see the relationship between the "always run in background" preference and the lack of feedback for the task at hand. This problem is even worse when the operation is not depicted in a view, where additional feedback could be shown. For example, "Help>Check for Updates" has no associated view so the only feedback is the progress in the status. Possible solutions: - flash the progress or some other more obvious thing. The trick is to balance between being noticeable and not annoying the user when they know what's going on. - use the concept of job family to determine when/how the preference is honored (perhaps the first time a job of a particular family is run, the dialog comes up anyway?) - expand the API somehow so that the preference is remembered per type of job. Another suggestion was to bring progress view to the front, but this would defeat the purpose of "always run in background" unless done selectively. And if we have a mechanism to do it selectively, why not just use that mechanism to bring the progress dialog up front when needed?
Another similar example is invoking Project > Build All. In this case there is also no particular view associated with the job so there is no other clear place for additional affordances (although the problems view, if present, will use italics to indicate change is underway).
I like the idea of a subtle animation in the progress bar to indicate that something is happening. But then, progress is platform specific so not sure what design parameters we have here.
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.
