Community
Participate
Working Groups
When a task is open in the rich editor and it is synchronized and found to have changes, a warning icon and message is given to the user. The message says "Task has incomming changes, synchronize to view". It is expected that the user clicks the refresh button in the right hand corner of the editor, however this message seems to tell the user to synchronize the task, not the editor. If a user does this, the editor is never refreshed until it is closed and reopened. I think that the message should be changed to reflect that the editor needs to be refreshed, not the task, and direct the user to where the refresh button is, or hyperlink the message so that clicking it will refresh the editor.
It makes sense to add a link to refresh right into the message. It also seems like current color used for this message (look like yellow-brown to me) is not very noticeable. Can we make that color configurable? I actually wonder if background for the whole header should change to the color used for changed attributes.
See this blog about customizing form colors. http://eclipsenuggets.blogspot.com/2007/03/get-custom-colored-forms-in-4-easy.html
I believe that the warning color comes from fonts and is intended to be subtle. I don't think that the header color should change unless the refresh happened automatically, because currently it is saying "stale" and that would say "changed". Regarding the description, the idea was that we avoid adding both a notion of "Refresh" and "Synchronize" and just keep things simple by using the latter. However, as indicated this is not quite working. I wonder if we could do the following: * Come up with a good color for "incoming/changed". * Automatically refresh the contents of the editor, and change the header color ass suggested if that's happened, to indicate to the user that there is new content since the last opened the editor, but to avoid having them repeatedly click the button.
(In reply to comment #3) > * Automatically refresh the contents of the editor, and change the header color > ass suggested if that's happened, to indicate to the user that there is new > content since the last opened the editor, but to avoid having them repeatedly > click the button. When would the task get marked as read? If the editor updates but the task keeps the incoming status this could be confusing. If we update the editor marking the task as read (no incoming arrow) but the editor was never actually revealed and just closed they will effectively missed incoming. Perhaps a selection listener on the editor causing mark read if the select otherwise remains incoming?
Right, this could be too confusing, because the task would have to lose its incoming indicator as you suggest. Or perhaps it could lose it when the editor first got focus?
(In reply to comment #5) > Or perhaps it could lose it when the editor first got focus? Pleeeeeease remove incoming indicator AFTER editor is closed.
(In reply to comment #6) > Pleeeeeease remove incoming indicator AFTER editor is closed. Wouldn't that go against the UI idiom used by most email readers?
(In reply to comment #7) > Wouldn't that go against the UI idiom used by most email readers? Most email readers actually allow you to set a timeout how long you have to look at email before it will be marked as read, more over, most of these editors don't use "show only unread" by default. So, I don't think your example is exactly fits with this use case. More over, it is actually completely opposite to how Mylar's own filtering works for Package Explorer, which unfilter things when editor is opened and filter them out when editor is closed.
(In reply to comment #7) > > Pleeeeeease remove incoming indicator AFTER editor is closed. > Wouldn't that go against the UI idiom used by most email readers? This is not really related to this bug summary, but I think interaction model in mail reader is different from Mylar because mail readers are using master/detail UI and email content is much less structured/complicated then task content. So, for them moving to next email mean it is been read. For Mylar you may open editor, then go into some other one without actually reading bug. On top of that, read issues disappear from the task list (and that is bad because we can't drag them nor call additional actions), which is also not the case for email readers.
Let's get the failure case of this done (missing task data) for 2.3.
Created attachment 89693 [details] patch to make missing task data refresh work with hyperlinking
Created attachment 89694 [details] mylyn/context/zip
(In reply to comment #10) > Let's get the failure case of this done (missing task data) for 2.3. Done. Deferring further improvements post 2.3
What is left to do here? Mik and I changed the message to "Task has incoming changes" and the message is a hyperlink now.
Until I forgot. If you submit some comments and get back "mid-air collision" error. "Incoming changes" message does not appear...
Eugene, it would be great if you could create a new bug to address the mid-air collision bug you've raised.
