Community
Participate
Working Groups
Bug 303517 has been committed to HEAD. As part of this we would like to make the following API changes in 3.7M7: 1) Promote the preference String for this to public API. Currently the String is in RefreshManager, but would like to move it to ResourcesPlugin#PREF_LIGHTWEIGHT_AUTO_REFRESH next to PREF_AUTO_REFRESH. 2) Change default of PREF_LIGHTWEIGHT_AUTO_REFRESH to true. Currently this functionality is turned off. Users, for the most part, shouldn't need to be aware or care about resource sync state (which is an internal eclipse workspace concept). With this preference off, when Resources are discovered out-of-sync the only way to proceed is to manually refresh the resource.
I raised a separate bug just for the API change i.e. 1) Promote the preference String for this to public API, see Bug 341075. I'm leaving this bug to address 2) which is a separate issue.
"shouldn't need to be aware or care about resource sync state" +1 Please see bug 363240 also. As this isn't on by default, users can get a lot of unnecessary errors reported simply because some resources have not been synched. As we can handle this case through resource synching, this would be a nice bonus for user quality perception.
James, are you looking at this during 3.8?
*** Bug 373051 has been marked as a duplicate of this bug. ***
Would be great to have the "Refresh on Access" turned on by default. I would also think that the preference setting could be removed, as I personally do not see a reason why someone should manually refresh.
I am not sure if removing the pref is good during M6. But enabling the feature by default could make sense. The idea was to do it (or not) based on the community feedback. There was no feedback (till now), so we were not looking at it.
For the feedback I got via Twitter, people would like to have this as default. I asked again, lets see if people post feedback on this bug. It seem a big hurdle for people to give feedback via bugfilla
(In reply to comment #7) > For the feedback I got via Twitter, people would like to have this as default. > I asked again, lets see if people post feedback on this bug. It seem a big > hurdle for people to give feedback via bugfilla Bugzilla is the right tool to gather community feedback. It would great if you could point them to this bug.
Hitting the error dialog for outdated resources every now and then while doing a workspace search keeps getting me up to get a new coffee. Getting rid of this problem would actually help to stay focused, +1 from my side :)
I haven't been aware of the preference until Lars twittered it some time ago. I don't see a reason why true shouldn't be the default.
Yes, please make this a default. I constantly forget to set this in my workspace and get the nasty search errors.
(In reply to comment #5) > Would be great to have the "Refresh on Access" turned on by default. +1 > I would also think that the preference setting could be removed, as I > personally do not see a reason why someone should manually refresh. -1 Please let the preference there. You never know which legacy Eclipse piece of software will strike back. I guess this was the reason why this preference is still disabled by default.
(In reply to comment #5) > Would be great to have the "Refresh on Access" turned on by default. +1
(In reply to comment #5) > Would be great to have the "Refresh on Access" turned on by default. > > I would also think that the preference setting could be removed, as I > personally do not see a reason why someone should manually refresh. Searches would be a lot less confusing. It doesn't matter how many times I dismiss the annoying dialog, it always surprises me. :-) +1
I think there are generally two groups: 1) Users who use Eclipse in conjunction with other external tools which modify the same files. These users fully expect the file to be changing without Eclipse's knowledge and just want the bloody dialogs to go away. I think the adoption of Git has made this group much larger than it was a few years ago. 2) Users who only interact with the files via Eclipse, for whom finding out that the file was changed by "something else" would be surprising, rare, and noteworthy. There are also other uses of eclipse core.resources, such as command line and headless server applications. For these applications in particular I think a mismatch between the resource model and file system should be treated as an error when the IResource.FORCE flag is not specified (otherwise we are breaking a very clear and long-standing contract in the resource API). Headless clients will typically either manually synchronize the resource model when they know it has changed, or use the FORCE flag to ignore synchronization problems if they truly don't care. One possibility here is to set the preference at the Eclipse IDE product level using the product customization mechanism (similar to how we set the default perspective and various other settings). This would be a more targeted change that would not impact other sorts of applications. On the downside, other IDE-like applications that want the same behaviour would also need to change the default setting in their product customization (as they do today).
@John: I think Group 2.) might not really exists, expect in a testing team which is hunting down bugs. I think all users of an IDE based product would like to avoid a manual step. Based on the requirements of 2.) I suggest to have this preference setting available (for testers) but still change the default so that Eclipse users are a little bit more happy with their favorite IDE. :-)
I looked at older bugs to find the reason why we did not enable the old auto refresh mechanism (hooks & polling). As I recall the reason was performance, but also the fact that "polling mechanism" works not only for resources backed by local filesystems but also for those backed by remote ones (like those provided by RSE). So what I think we really need is to add all remaining native hooks (for Unix and Mac, see Bug 108697, Bug 237344), then enable "Refresh using native hooks" by default. Till then, people can use "Refresh on Access" or "Polling mechanism" which is not enabled by default for reasons mentioned above.
@Szymon If I understand your comment correctly you are suggesting not to enable this by default. I think by this we are punishing 98% of the users, to save 2% of users which might be working with remote resources. To my knowledge SAP uses remote resources in there Netweaver ABAP IDE but I would assume that if required they can override this preferences setting in Netweaver. But as an (former) employee of SAP I also would claims that SAP ABAP would like to have auto-refresh. I don't think that users of remote resources are happy to press F5 to get the correct data. The bug report started with the request that users should provide feedback if this should be enabled by default. So far no user disagreed with the activation of this flag. It would be great to use this feedback.
There are still some issues with saving resources while building. Please refer to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=351655. BTW: We are working on a big C++ project on NFS. Refresh of it could take more then 1 minute. During this time you cannot performe save actions, etc. In my opinion we should be very careful with changing the default preference. Thanks, Yevgeny
@Yevgeny: This bug is for "Refresh on Access", e.g. whenever the user open a updated file it should refresh automatically instead of showing that the user should press F5. How long does a refresh take for a single resource in your project?
(In reply to comment #20) > @Yevgeny: This bug is for "Refresh on Access", e.g. whenever the user open a > updated file it should refresh automatically instead of showing that the user > should press F5. > How long does a refresh take for a single resource in your project? Sorry, I missed this part :-) On single file, I do not see an issue here. Even if it is a big file, refreshing it is fast.
(In reply to comment #16) > @John: I think Group 2.) might not really exists, expect in a testing team > which is hunting down bugs. I think all users of an IDE based product would > like to avoid a manual step. That group does exist ;-). I can't remember when I used an external tool to modify one of my Eclipse files. Hence, I strongly prefer the way it currently is, because I want to know if something changed behind my back. (In reply to comment #18) > @Szymon If I understand your comment correctly you are suggesting not to enable > this by default. I think by this we are punishing 98% of the users, to save 2% > of users which might be working with remote resources. From where do you have those numbers? I would claim that those who are happy with the existing behavior don't raise their voice because they are happy and because they might not be aware of the suggested change. Having said that, removing the preference won't happen. Regarding the default: if we hold a more publicly visible poll (e.g. via eclipse.org mailing list) that shows more people desiring to change the default, then I'm fine with that.
@Dani: How would you affect if auto-refresh would change its default? If you only change via Eclipse and don't use any external tools you would see no difference. If you want to hunt done bugs, you can change the setting for yourself. The only reason I heard why it should not be changed it to make it easier for the Eclipse committers to find bugs, which is IMHO not a good default setting for an general purpose IDE. The bug asked for feedback from users, which was received, now the bug asked for a different way of getting feedback. Changing the rules usually indicates that the resistent is to strong. I personally will now get quite on this bug, I think the current setting is very unfriendly to new Eclipse users but the expert Eclipse community seem resistent to change the current behavior.
* Change default of PREF_LIGHTWEIGHT_AUTO_REFRESH to true. +1 because that's what I think is useful to most users and allows to change the behavior for special circumstances.
(In reply to comment #23) > @Dani: How would you affect if auto-refresh would change its default? If you > only change via Eclipse and don't use any external tools you would see no > difference. If you want to hunt done bugs, you can change the setting for > yourself. It's more about getting notified if I (or some code) unexpectedly changes my files plus the performance impact that got mentioned before. But yes, I could change the setting myself once the default changed. > The bug asked for feedback from users, which was received, now the bug asked > for a different way of getting feedback. Changing the rules usually indicates > that the resistent is to strong. Don't get me wrong: if the community really prefers to change the default I'm all in. My problem with this bug is that it is not publicly announced. Most people on this bug are those who prefer the new behavior or who asked their "friends" to also vote.
@Dani: As mentioned earlier the feedback on Twitter and G+ was also very strong in favor of this change but I was asked to guide them to this bug, see comment #7 Can you send an email to the distribution list you would like to get notified so that more people get to raise their voice in this bug? If desired I can write a blog entry for PlanetEclipse to get a broader audience to see this.
(In reply to comment #26) > @Dani: As mentioned earlier the feedback on Twitter and G+ was also very strong > in favor of this change but I was asked to guide them to this bug, see comment > #7 > > Can you send an email to the distribution list you would like to get notified > so that more people get to raise their voice in this bug? I guess the cross-platform and the committers mailing list would be good. I'd appreciate, if you could do it as I'm pretty busy getting M6 out of the door. Please mention the pros and cons in the mail. A blog entry also doesn't hurt.
@Dani: As you raised concerns about the objectivity of the voting people in this bug I think it would be better if you send it out. To save your time I can prepare the email, send it to you, you could revise it to emphase the negative points (which I still don't see) and send it out. Ok?
If i understand it correctly the resource that is out of sync has to be refreshed no matter what the value of this preference is, right? The choice that has to be made is: do you want to interrupt the user only to notify him that a resource has changed outside eclipse or not? Personally i prefer refreshing automatically. But thinking further i think part of the problem is the way the user is notified: a modal dialog is very disruptive. Maybe changing the way the notification is done (for example a notification bar at the top of the editor that slowly fades) might reach a middle ground. (Although this is something that probably has to be discussed in another thread.) (In reply to comment #22) > > Having said that, removing the preference won't happen. Regarding the default: > if we hold a more publicly visible poll (e.g. via eclipse.org mailing list) > that shows more people desiring to change the default, then I'm fine with that. +1
(In reply to comment #29) > But thinking further i think part of the problem is the way the user is > notified: > > a modal dialog is very disruptive. Maybe changing the way the notification is > done (for example a notification bar at the top of the editor that slowly > fades) might reach a middle ground. (Although this is something that probably > has to be discussed in another thread.) I was thinking about it today too. We could raise a separate bug for that. Even if I do not have auto-refresh enabled by default and I have to enable it manually, I would still like to know what was automatically refreshed. Some kind of fading, non-modal message could be nice. I'm not a big fan of auto-refresh. As Dani, I prefer to know what is going on underneath. What would help me is something that shows me that my resources tree is out-of-sync with filesystem, then shows what it is and refreshes all out-of-sync resources with one click. In other words, auto-refresh mechanism would not refresh automatically, but would just collect changes to refresh, and it would be me who triggers the refresh for collected resources. Like in Mylyn editor, I'm notified that something was changed, but I have to refresh manually.
@Szymon this would IMHO useful for the setting"no auto-refresh". You would get notified and could refresh with one click.
(In reply to comment #22) > Hence, I strongly prefer the way it currently > is, because I want to know if something changed behind my back. (In reply to comment #30) > I would still like to know what was automatically refreshed. Some > kind of fading, non-modal message could be nice. I think both of the above are wrong for one good reason: *any* change to your files by an Eclipse plugin will happen without you knowing it. Team providers, editors, builders all change your files, silently update the sync state. In fact, egit has a feature whereby it does a full refresh whenever it sees HEAD change... I don't see how this state is every useful to a user of the IDE. 'refresh' sync state is nothing more than an implementation detail of eclipse core.resources notification mechanism. Is there any other IDE or editor that expose this to users? Really: why would anyone, other than a core developer debugging that platform's resource notification, care? (In reply to comment #25) > It's more about getting notified if I (or some code) unexpectedly changes my > files plus the performance impact that got mentioned before. Performance impact? The system _already_ checks whether files are in-sync by doing a stat on every read. It only does another stat to bring the file back into 'sync' when it discovers it out-of-sync.
(In reply to comment #30) > I'm not a big fan of auto-refresh. As Dani, I prefer to know what is going on > underneath. What would help me is something that shows me that my resources > tree is out-of-sync with filesystem, then shows what it is and refreshes all > out-of-sync resources with one click. > In other words, auto-refresh mechanism would not refresh automatically, but > would just collect changes to refresh, and it would be me who triggers the > refresh for collected resources. Like in Mylyn editor, I'm notified that > something was changed, but I have to refresh manually. While I think that a batched "Out of Sync-refresh?" dialog with the complete out of sync tree would be an improvement over (a replacement for) the current "pop up a dialog for every editor" behaviour, I don't believe it's a replacement for this preference which is truly "yes, just reflect the file system and I'll take my chances" approach. So the next step as Dani mentioned is to set up a poll (doodle, anyone :-) and post it to cross-projects and the committer list. Lars will organize it (with help posting if he needs it from Dani or I). PW
(In reply to comment #25) > It's more about getting notified if I (or some code) unexpectedly changes my > files plus the performance impact that got mentioned before. If by performance impact, you mean bug 344954. That only arises because there's a code-path which *ignores* sync state, in JDT of all places: https://bugs.eclipse.org/bugs/show_bug.cgi?id=303517#c94 Don't you believe that all platform code should call File#getContents(force=false) ? In reality there aren't many places which do getContents(true) in the platform, so I expect the change, as it stands to be negligible to real users. If that doesn't convince you, it's trivial to make getContets(force=true) behave the same as it did before, so performance with the preference on or off would be identical. => I don't believe there's a performance argument to be made here.
John, you own the bug. Are you fine with a poll i.e. would you also accept the result? We could do the poll via Eclipse infrastructure: http://wiki.eclipse.org/Using_Phoenix#Using_polls
If desired I can setup a Google Form or Doodle for voting. Using Eclipse Infrastructure would also be fine but then some else need to set this up. Once John gives his feedback, let me know if I should set this up.
I was already planning on changing the default as described in comment #15, but if someone wants a poll, go ahead. I completely agree for Eclipse IDE use case most users will just want it to refresh.
(In reply to comment #37) > I was already planning on changing the default as described in comment #15, but > if someone wants a poll, go ahead. I completely agree for Eclipse IDE use case > most users will just want it to refresh. OK, if you also agree to change the default and if this is done at the IDE level, then let's try it. We can still revisit if people complain about it.
@John: super cool thanks! I would like to state that I personally don't directly benefit from this, as I'm of course aware of this setting and can easily change it. But I have seen a lot of user complains (and some jokes) about failing Search and Refresh. I think its helpful to new users, if we change this. Thanks to all for this great discussion.
Definitely a big +1 on this change.
A big +1 indeed. I have been developing eclipse plugins for almost eight years now and I can't think of any good use for this feature at all. Most of the times it just causes unnecessary defects that occur because files got modified and workspace wasn't refreshed. I have seen a lot of new comers struggling with this early on and developing really bad habits to avoid syncing problems. Like for example, I know one user who doesn't trust "refresh" action at all and constantly closes/opens projects to ensure that the files are not out of sync with the file system.
http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?h=R4_HEAD&id=624dafba89ca9abed4397b97a1fb97b1c1b4e27f Leaving open to verify.
Released.
Verified in I20120410-0633.
Thanks!
Was this commit included in Eclipse 4.2? If I switch to a new workspace the option "Refresh on Access" is not set.
(In reply to comment #46) Please do not open already verified bugs. > Was this commit included in Eclipse 4.2? Yes, you can verify this by simply starting a new workspace. > If I switch to a new workspace the option "Refresh on Access" is not set. That would be a separate bug along with steps to reproduce. JFYI, these steps work fine for me: 1. download http://download.eclipse.org/eclipse/downloads/drops4/R-4.2-201206081400/ 2. unzip 3. start new workspace 4. switch to another new workspace ==> 'Refresh on access' is enabled
Here is my test: 1.) Download new Eclipse RCP and RAP package for Linux eclipse-rcp-juno-linux-gtk-x86_64.tar.gz 2. unzip 3. start new workspace -> Refresh on Access is not enabled 4.) Switch to new workspace -> Refresh on Access is not enabled Maybe an issue with Ubuntu 12.04? Can someone with Ubuntu 12.04 retest? @Dani: Why not open an existing bug if the fix does not work (for me)? Can you please point me to the Eclipse guideline for that?
(In reply to comment #48) > Maybe an issue with Ubuntu 12.04? Can someone with Ubuntu 12.04 retest? Pleae test with my steps from comment 47 and report back.
> @Dani: Why not open an existing bug if the fix does not work (for me)? Because it is easier to track with a new bug and we *did* fix the bug. Maybe it's not working on a certain EPP or on Mars, but in that case we'd prefer to track that in a separate bug. > Can you please point me to the Eclipse guideline for that? Each project uses a little bit different processes in bugzilla. There is no rule that forces a certain process.
Hi Dani, I tested with the official release (Build id: 20120614-1722) otherwise our steps are the same (as far as I can see). Looks to me that I'm using a newer release (20120614>20120608). Could you maybe give the newer release a try? Best regards, Lars
Eclipse Classic download works fine. Closing as advised by Dani as this is fixed.
Lars, I suggest to file a bug against EPP. Either the package or one of its plug-ins probably overrides that setting. Please cc me on the bug. Thanks.
Bug 384104 opened. I agree that this issue belong in a new bug, as it seems to be related to the packaging. Thanks for your help Dani.
+! Has this been made default setting yet? I ask because in latest Luna I had to enable this however I am using an existing Workspace.
(In reply to Daniel Sokolowski from comment #56) > +! > > Has this been made default setting yet? I ask because in latest Luna I had > to enable this however I am using an existing Workspace. Al EPP should have this setting on by default for a new workspace.
