Community
Participate
Working Groups
I am running 3.2RC7 on a project with ca 2,500 files so its quite big. But whenever I edit a source file and save it Eclipse rebuilds the workspace. But it takes far too long and during that time the GUI is unresponsive. Presumably rebuilding the desktop is running on the Swing thread? This really needs to be put in a separate thread so that it doesn't block the GUI. Obviously there is a fair amount of processing required for a large project like that which I am working on and the syntax colouring, error reporting etc is dependent on the re-parse of the whole project but locking up the GUI for >30 secs is simply not acceptable from a user responsiveness point of view. Suggest running in a separate thread. Often the user wants to navigate or view files which will not be affected by a workspace rebuild. I am aware that another bug reports the same problem but that mentions it being fixed in RC5 and is to do with J2EE/Tomcat so if it is the same bug it is definitely not fixed.
Not sure I understand correctly. The build process is already occurring in background. If you are talking about the build progress dialog in your way, you can go to preferences and tell it to send operations to background automatically (this is what I use on daily bases). Window>Preferences>General>Always run in background Are you rather talking about UI freezing ? If so this would be really bad, and I would encourage you to produce a reproduceable scenario which we could investigate. We are building workspaces with far more than 2,500 files, and UI remains responsive all the time. You may want to launch Eclipse with console open (using java.exe instead of javaw.exe on command line), and once OS console opens, while Eclipse is misbehaving, go to console, and press ctrl-break for causing VM activity dumps. These may reveal the problem. Alternatively, you may want to look at external tools getting in the way, like antivirus realtime checks etc... which may alter drastically your I/O performance, and thus affect build times.
OK apologies. I should read the Help Guide more carefully. Confirm that with the Window>Preferences>General>Always run in background preference set there is no problem. Closing this as Not A Bug.
Good. Also note, that when build is in progress (and pref for sending to background is disabled) you may still manually press a button in the build dialog to send it to background (for this one instance). Personally, I prefer the global pref.
Actually, moving to platform/ui. I think this reflects a perception issue. The sending to background should be made more proeminent. 1. why do we think sending to background shouldn't be on by default ? 2. what about having a button for sending ALL build ops to background ?(from build progress dialog)
Re: comment 2 Basically, you should not have needed reading the doc to figure this. This is why I moved this for further consideration to UI
This one was still in the Platform/ui bucket.
Yes indeed. Would you please be kind enough to comment on Philippe's suggestions (comment #4)?
(In reply to comment #7) > Yes indeed. Would you please be kind enough to comment on Philippe's > suggestions (comment #4)? Sorry for moving this (and other bugs) around - its component was set to Platform/UI but the assignee was not platform-ui-inbox. When we do bug triage, our query is to look at all bugs that are assigned to platform-ui-inbox, and therefore, we don't see bugs that are just moved to a different component but still assigned to someone else.
We bring up the dialog explicitly whenever a job is a user job. If the JDT Core team didn't want this functionality they could set thier job to not being a user job. We do not turn off Run in Background by default because it is specifically meant to support jobs that can be run in the background that are significant enough to prompt the user. There have been requests for us to implement someway of doing a "Don't show me again" which we could do based on Job families (or something like that) but we won't be changing the default value on Always Run in Background.
Reopening for discussion in the platform UI team. For Android development I use Android Studio and its annoying popups for jobs, made me realized that our option to run jobs in the background is a real gem. I suggest to activate it by default so that more users have a pleasant out-of-the-box experience.
+1 I wonder who likes the dialog and why? We disable this by default in our install so that I forgot that this is actually still there.
(In reply to Lars Vogel from comment #10) The default to not run jobs in the background never made any sense to me. At Google we have Always Run in Background enabled by default and haven't heard any complaints.
For the record, we also we it for some of our customers with Saneclipse (https://github.com/vogellacompany/com.vogella.saneclipse) and never heard complains.
+1 Good Idea!
*** Bug 111600 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/76653
+1 I really dislike the amount of dialogs. Not to mention they cause real issues sometimes when there is a bug in window managers where they stay behind the main window and the UI looks stuck to the user but it's just the dialog being in the background.
Gerrit change https://git.eclipse.org/r/76653 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=2d942fd981f42ef7553d13e27dff512a18e331c7
Thanks everyone for the feedback. Default has changed. I will request a downport from the PMC soon.
(In reply to Lars Vogel from comment #19) > Thanks everyone for the feedback. Default has changed. I will request a > downport from the PMC soon. +1.
If I recall correctly from the time, the progress dialog was first introduced as a way to provide user feedback for explicitly-initiated gestures. Without the dialog, a new user could trigger an action that spins up a job and be under the false impression that nothing was happening in response (if you're not aware of the progress indicator in the lower-right, it could seem as though Eclipse had ignored your gesture). I believe that the intent of the progress dialog was to train new users about the meaning of the progress indicator in the lower-right and the assumption was that experienced users would all discover and enable this preference. Now that the preference is on by default, the dialog box serves no purpose at all. It may have been helpful to train new users at one time, but it's unlikely that any user will intentionally re-enable the preference. For this reason, I'd suggest that we delete both the dialog box and the preference. However, we're left with an unresolved problem: how will we help new users discover the progress icon in the status bar? I'd suggest that the first time we start a user job, we open a little popup window in the lower-right with a message along the lines of "Eclipse has started doing some work in the background. If you'd like to watch its progress, click this icon." It can have a little arrow pointing to the progress icon. It need not take keyboard focus, and typing any character or clicking the mouse can dismiss the popup. After we show it the first time, it never needs to come back. I believe this would address the only useful function that the progress dialog used to serve. In short, I'm asking for two bits of follow-up: 1. Delete this preference and the progress dialog. 2. Offer a quick tutorial for users the first time they see the progress icon.
Extracted bug 497429.
Extracted bug 497430.
I have concerns with this change. In our code we use jobs when we do not want to lock the UI. However, we _do_ want to keep the user informed of that jobs progress with the dialog. It would be very inconvenient for us if this default was changed. In our application we are dealing with end-users that will have no clue what is happening and will request the action again because they think that nothing has happened. Before this change is implemented I would like to have an alternative on how to keep the current feature. Note that there are already two ways to omit the dialog. 1. The user can press the "Always run in background" in the dialog. This has to be done only once. 2. The programmer can run their jobs as SYSTEM which does not provide (non-modal) dialog.
(In reply to Alexander Kurtakov from comment #17) > +1 I really dislike the amount of dialogs. You can press the "Always run in background" in the dialog only once and be freed of this problem. > Not to mention they cause real > issues sometimes when there is a bug in window managers where they stay > behind the main window and the UI looks stuck to the user but it's just the > dialog being in the background. This is not the case. The jobs dialog is not application modal and therefore does not lock the UI. Even if it was the case, the jobs framework is not responsible for bugs in the window manager.
Created attachment 263206 [details] Movie explaining my POV.
Wim, for your product you can change the default as with any other preference. We were also planning to delete the preference, I assume you are against that. Discovery issues of background jobs should be discussed via https://bugs.eclipse.org/bugs/show_bug.cgi?id=497430.
Whatever we decided, it's definitely not something we should backport to 4.6.x.
(In reply to Dani Megert from comment #28) > Whatever we decided, it's definitely not something we should backport to > 4.6.x. +1
Wim, could you describe your use-case in more detail in bug 497430? If we're going to support it, we should understand it better to ensure that we do a good job supporting it.
(In reply to Lars Vogel from comment #27) > Wim, for your product you can change the default as with any other > preference. For the product we can but not for the plugins where we run inside Rational. It would not be prudent for a plugin to change the host preferences. > We were also planning to delete the preference, I assume you are > against that. Discovery issues of background jobs should be discussed via > https://bugs.eclipse.org/bugs/show_bug.cgi?id=497430. Not so much against the change but I would like to be able to keep the behavior in some way.
(In reply to Stefan Xenos from comment #21) > Now that the preference is on by default, the dialog box serves no purpose > at all. It may have been helpful to train new users at one time, but it's > unlikely that any user will intentionally re-enable the preference. For this > reason, I'd suggest that we delete both the dialog box and the preference. Please do not remove the dialog and if you remove the preference please provide API to popup the dialog in a different way. Here is my use case: Default way of detaching long running jobs is the Jobs framework. However, sometimes the user is waiting for the result of the job. For example, in our tool we are doing a checkout. We don't want to put this in a UI dialog because it can take too long. In theory, the programmer can do other stuff but the practice is that the developer wants to wait for this job to finish before he can start coding on the checked-out objects. Using the dialog the programmer monitors the checkout. We display all sorts of progress information on this dialog through the monitor. Please see Comment 9 which exactly describes what I mean.
Created attachment 263223 [details] Our checkout dialog.
(In reply to Wim Jongman from comment #32) > (In reply to Stefan Xenos from comment #21) > Please do not remove the dialog and if you remove the preference please > provide API to popup the dialog in a different way. Deletion of this preference and its dialog should be discussed in Bug 497429.
New Gerrit change created: https://git.eclipse.org/r/77656
Gerrit change https://git.eclipse.org/r/77656 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=4ba8df1ccd75818b750e124d743a6b06b508d96e
(In reply to Wim Jongman from comment #31) > For the product we can but not for the plugins where we run inside Rational. > It would not be prudent for a plugin to change the host preferences. In this case you can not rely on a default to notify your users. If the user triggers another action before your and select "always run in background" before triggering your action he will not be notified. -2 for changing the default back. We should have reasonable setting for most users in the Eclipse IDE Having one global setting does not help with discovery for new users, as you never know what they have been doing before. If you want a standard way to notify your users, please comment or consider contributing on Bug 229823.
(In reply to Lars Vogel Unavailable until 15 August 2016 from comment #37) > users in the Eclipse IDE Having one global setting does not help with > discovery for new users, as you never know what they have been doing before. true
Similarly to Wim, I have some use cases for which I believe that users want to be aware that some time is necessary before they can carry on their workflow. With the progress hidden by default, users will have the impression that things -completion, hover...- don't work without understanding that a few seconds are required by a job to initialize a few things. With the job being shown, they know that some time is necessary and then they're free to decide whether they can continue with or without it. Most of the time I see a progress dialog in Eclipse IDE, I find it informative and I have the impression it helps user to better understand what's going on, what to expect and to decide how much they want to care about it. I have the impression that hiding all progress dialogs by default is going to add much confusion for a very small gain (some clicks on "Run in background" from time to time).
Mickael, can you tell us more about the workflow you're doing? Is it an task the user initiates and then needs to supply more input for after the background job completes? Or are you concerned that the user will be unaware that the operation completed successfully? Is there some UI associated with the background task? Depending on the answers to these questions, perhaps there's a different UI metaphor that would serve your users better -- or perhaps if it's just awareness of the background operation that concerns you -- we could resurrect bug 497430.
The use-case is usage and initialisation of asynchronous services for, let's say, hover. Imagine computing a hover is a long operation (in my case it can require initialization of Omnisharp, a dotnet program which takes some time to start), then the user who gets on a word to get the hover will just see nothing while initialization is taking place. They go on, and don't even know hover is supposed to happen. Whereas if there were some Progress Report, they'd be aware that some language server initialization is happening, and they'd understand that after it's completed they should get what they asked for. For sure there would be better metaphor for this: asynchronous hover, asynchronous completion proposal, asynchronous everything. However, those are currently not asynchronous in the Platform and it's not simply a matter of changing some UI metaphor to something else -it's about changing hundreds of complex lines in the core parts of the IDE-, so it's a tremendous and unaffordable effort at the moment. Many parts of Eclipse IDE are IMHO not ready to handle asynchronous operations properly, presenting them to users in an elegant way, giving the right level of information/control in the right context... The Progress reporter dialog is at the moment the best thing there is, and I'm not sure we can really live well without it at the moment.
(In reply to Mickael Istria from comment #41) > The Progress > reporter dialog is at the moment the best thing there is, and I'm not sure > we can really live well without it at the moment. I agree. It is broken because the functionality is global. In cases where you require the progress dialog, like you do with hover, the only thing you can (and must) do is set the preference to your required value. Therefore this change will not effect that and I agree to set it on "run in background" by default. However removing the preference AND the dialog as suggested in bug 497429 is something else. It would be nice if we have something to replace the current API and allow progress dialog based on some attribute of the Job. Let's continue this discussion on bug 497429.
Re: comment 41 You're right -- an asynchronous API for computing hovers would be the best solution here. You'd want to see the hover immediately with some sort of spinner or message saying "Computing contents...", then it would fill in once the data comes back. So I guess we're talking about short-term workarounds until someone is able to investigate doing this properly... and in this case, we're faced with a choice between two equally-horrible options: either you use Jobs and risk seeing no progress at all or you use your own progress dialog and risk interrupting the user with a progress dialog seemingly at random. Personally, I would prefer risking doing nothing than risk interruption (and I disable all the hovers in the workbench for exactly this reason), but it shouldn't be the job of platform to impose any particular workflow on plugin authors. So yeah - I agree there should be a way for a plugin author to create a progress dialog if they want one. Re: comment 42 I was going to suggest the use of ProgressMonitorDialog, but I can see why you wouldn't want to use it: the JavaDoc on "run" says that it blocks until the job completes, which is a deadlock risk. However, what if we had something very much like a nonblocking ProgressMonitorDialog? Would that address your concerns? I agree it makes sense for the code initiating a job to choose between showing it to the user and not. That code knows what the Job is used for and whether or not the user needs to see it. However, I don't think this should be a flag on Jobs. The best such a flag could do is open a generic progress dialog like the the one we have now, which isn't very informative. If the code initiating the job is opting in anyway, it can opt into a much more specific UI that is tailored to its use-case (like the hover-with-embedded-progress-monitor I described, above). Sure, one of the options could be a generic progress dialog... but I'd think that in most cases, we can do better.
(In reply to Stefan Xenos from comment #43) > Re: comment 41 > > You're right -- an asynchronous API for computing hovers would be the best > solution here. You'd want to see the hover immediately with some sort of > spinner or message saying "Computing contents...", then it would fill in > once the data comes back. Hi, I filed [1] for this. [1] Bug 499992 - Provide better API for monitoring the progress of Jobs
Some of current user stories where IMO we should keep a progress report dialog by default: * Search on a whole workspace: AFAIK, there is no other progress reporting at the moment * JDT's "Show type hierarchy" In those 2 cases, if there is no progress report, user gets the impression that the feature either doesn't work at all, or not well.
