Community
Participate
Working Groups
I20070320-0010 Scenario: - create new file test.txt in project P; - edit it; - leave Eclipse; - touch test.txt; - launch Eclipse; - answer 'No' to the 'File Changed' prompt; - you get your editor to display 'Resource is out of sync...'; - while refreshing it from the Navigator is easy, I found no means to refresh the resource from the editor itself, which I find non intuitive. Note: that behavior is somewhat general and other scenarios enable to display the file contents instead of the 'Resource is out of sync...' disclaimer, for which a contextual menu is available, but that menu has no refresh item. Checked behavior for Linux and XP.
Right. We should at least retarget File > Refresh (F5). Putting more work into this like adding a button or a context menu is overkill as the user was explicitly asked previously and he chose 'No'.
Retargeting F5 will be welcome. However, despite the fact that it is more work, I would still consider that adding a bit more would be a bless. The truth is that users would never deliberately pursue actions that would lead them to have a useless editor opened on the out of sync disclaimer. [I find the 'keep previous contents' scenario a bit stretched, but this may happen (followed by an optional override of the disk contents).] The only two reasons I see to reach the out of sync disclaimer are the following: - hast/mistake; the user does not read the message or simply hits the wrong button; - doubt; presented with an unexpected dialog, the user takes the safer path (do not reload, keeping both images). In both cases, once the sole contents you get are the disclaimer, your only reasonable choice is to refresh. And the means to do that should be obvious, prominent and seamless. I agree that then some users (and I will be happy to be one these) will remember that you've added F5. But others won't know it and will have to fuss around before getting the thing fixed. (I also agree that quite a few users will refresh the whole project or workspace, but...). Note that this also questions the out of sync disclaimer itself. If we cannot present usable contents, then we might be better off loading them anyway. But I assume that this design point has merits that have been debated elsewhere.
>Note that this also questions the out of sync disclaimer itself. If we cannot >present usable contents, then we might be better off loading them anyway. But I >assume that this design point has merits that have been debated elsewhere. This is the way Eclipse SDK does it everwhere (e.g. when you execute an action that modifies files). If all agree to always silently ignore the out of sync in the far future then the editor will do as well ;-)
Fixed in HEAD. Available in builds > N20070412-0010.
