Community
Participate
Working Groups
As per the discussion on bug 244441, this will help insulate us from incompatibilities between the our rich client and the server. Sits at <repo-url>/service-message.xml, e.g., https://bugs.eclipse.org/bugs/service-message.xml Suggested format: <message> <id>2009-09-03</id> <type>{warning, info, error}</type> <connector>bugzilla</connector> <version-repository>3.2.0</version-repository> <version-mylyn>3.0.3</version-mylyn> <summary>Bugzilla 3.2.0 not fully supported, click here to update.</summary> <details>... HTML formatted message pointing to update site, etc ...</details> </message> Message is checked whenever the repository configuration is updated. When the Mylyn version is smaller or equal to "version-mylyn" AND the task repository version is smaller than or equal to "version-repository" the "summary" String is displayed in the task editor's header, as the appropriate type, for each editor opened for that repository, unless user has asked to ignore messages. When user clicks the hyperlink for the message, dialog opens showing HTML-formatted summary of the message, and offers to not display again.
We might need to consider this for 3.0.4/3.0.5.
If this goes on the backlog I think it should be a P1, since every year we encounter problems which eat up a lot of time, and could be addressed with such a message.
API suggestion: AbstractRepositoryConnectorUi.getServiceMessage(), can return something ServiceMessage.OK if all is good.
Should I start with the implementation of the core code for this? 1) RepostioryConfiguration : add support for store the message 2) Bugzilla Client : add methods to get the xml file 3) RepostioryConfiguration : evaluate the ServiceMessage state
I accidentally changed this from P1 to P4. Frank: We discussed the design of this on the Mylyn call, so Rob will fill you in on that. Thanks for stepping up, this will be a very valuable feature.
(In reply to comment #4) > Should I start with the implementation of the core code for this? > > 1) RepostioryConfiguration : add support for store the message > 2) Bugzilla Client : add methods to get the xml file > 3) RepostioryConfiguration : evaluate the ServiceMessage state Since this will just be an additional xml file hosted on the server, is doesn't necessarily need to be part of the repository configuration (just retrieved at the same time perhaps). Might also want to consider using the preference store for maintaining the last read timestamp vs the configuration. This would make it easier to eventually pull up into the framework for other connectors to use.
I am in favor of storing per repository information on the corresponding TaskRepository object. It makes the life-cycle management easier and the same API available to all connectors. We already have several per-task/repository preferences that are not properly cleaned up when repositories are deleted or URLs are changed (e.g. editor mementos).
Good call Steffen, the TaskRepository properties is a perfect spot for this.
I think we can use this for our recently discussed feature of showing users when a Mylyn update is available, etc. So instead of the task editor, let's show this on the Task List view. Rob: shawn has some code in Tasktop that we can use for showing a nice gradient region at the bottom of the view. We just need a close icon on that, which we can take from the desktop notifications popup. I think the component itself should go into ..mylyn.commons.ui. In terms of UI, I think it should look like this: pre. [32px image] [bold title] [message text, up to 140 characters] Frank: I assume it makes sense to take this off your plate since you've got other important 3.4 stuff underway.
Just need to do some testing and will have a rough first pass done at this.
Created attachment 167544 [details] v1 First pass at this. Numerous things to consider and still a layout/wrapping issue with the ui. This version is rudimentary in
Created attachment 167547 [details] v1 First pass at this. Numerous things to consider and still a layout/wrapping issue with the ui. The message xml format is relatively simple at this point (see below) and uses a string identifier to add a standard message dialog icon in the top left. A close button is on the top right (but doesn't layout correctly when the task list is resized). The long description doesn't wrap either. Closing a message will result in that message not being displayed again. The message is currently retrieved from eclipse.org/mylyn/message.xml. <ServiceMessage> <id>1</id> <description>140 character description here....</description> <title>Mylyn 3.4 now available!</title> <url>http://eclipse.org/mylyn/downloads</url> <image>dialog_messasge_info_image</image> </ServiceMessage>
Created attachment 167548 [details] mylyn/context/zip
Created attachment 167550 [details] v1 Screenshot
Points from UI review: * Include preference for disablement * Include Mylyn version number at a minimum in order to ensure appropriate messages are displayed * Further investigation required to fix layout issue
* ETag support
Created attachment 169594 [details] v2 Includes Etag support, a preference for disablement, and ability to only display when installed Mylyn version is <= version specified in message xml. Layout issue remains.
Created attachment 169595 [details] mylyn/context/zip
Steffen, I need fresh eyes to look at the layout issue and review the progress made here if you get a chance.
Created attachment 169603 [details] v3
This looks pretty good Rob! I have applied a couple of changes: * The servicemessage package is now called notifications and exported as x-internal. Please make sure you have API tooling setup with a current base line to catch errors of this sort. * The enum identifiers in ServiceMessage are now all upper case to follow convention. * I replaced MylynVersion by the corresponding OSGi version and made the XML version a range. The element is now called version and not mylynVersion. * Why did the patch change the labels for weekStartCombo in TasksUiPreferencesPage? I have reverted that. * I changed the error logging to only occur once per session. * I removed the check for the content length header and instead handled 404 (i.e. no message available). You can not assume that server will always return a content length, e.g. when chunked encoding is used. * I added support for parsing of multiple message, e.g. if there are separate messages for different Mylyn versions * I unregistered the message listener on Task List dispose. * I used shared form colors for the rendering. Outstanding issues: * There needs to be a preference listener to disable the service control and to stop the job. Using a null message to handle that is not obvious and Go Into can actually make the message re-appear. * Polling every two hours is way too frequently. Isn't once a session/once a week sufficient? * I am a little concerned that control is always constructed even if a message is never displayed. How difficult would it be to construct and dispose the control as messages are displayed and hidden? * I managed to make the control visible without a valid message which caused null pointers. Some checks are missing. * Shouldn't there be a way to disable message from the message control? * What is the reason for nesting informationComp? Why not use head directly as a parent for the controls?
Wow, overhaul appreciated! ;) I expect to have time to pick this up again this evening or tomorrow. (In reply to comment #21) > Outstanding issues: > * There needs to be a preference listener to disable the service control and to > stop the job. Using a null message to handle that is not obvious and Go Into can > actually make the message re-appear. Yes this would be ideal. > * Polling every two hours is way too frequently. Isn't once a session/once a > week sufficient? Debatable. Maybe twice a week? Should of course be using pubsub... > * I am a little concerned that control is always constructed even if a message > is never displayed. How difficult would it be to construct and dispose the > control as messages are displayed and hidden? This could be done, I'll look into that. > * I managed to make the control visible without a valid message which caused > null pointers. Some checks are missing. Okay. > * Shouldn't there be a way to disable message from the message control? How about a check box lower left in a smaller font? [x] Disable > * What is the reason for nesting informationComp? Why not use head directly as a > parent for the controls? This is likely left over from some layout refactoring. Speaking of which, did you notice the layout issue I mentioned?
> > * What is the reason for nesting informationComp? Why not use head directly as > a > > parent for the controls? > This is likely left over from some layout refactoring. Speaking of which, did > you notice the layout issue I mentioned? Yes, GridLayout does not work well with wrapping. I changed it to a TableWrapLayout which seemed to fix it.
Patch (below) has the following addressed: * -There needs to be a preference listener to disable the service control and to stop the job.- * -I am a little concerned that control is always constructed even if a message is never displayed. How difficult would it be to construct and dispose the control as messages are displayed and hidden?- * -I managed to make the control visible without a valid message which caused null pointers. Some checks are missing.- * -What is the reason for nesting informationComp? Why not use head directly as a parent for the controls?- Outstanding issues: * Polling every two hours is way too frequently. Isn't once a session/once a week sufficient? * Shouldn't there be a way to disable message from the message control?
Created attachment 169740 [details] v4
Created attachment 169741 [details] mylyn/context/zip
Created attachment 169747 [details] v4 repost should have less cross contamination
Thanks Rob. I found two potential problems in a quick review (I wasn't able to test due to overlap with bug 302907): * Handling of the stop event in TaskListServiceMessageControl.handleEvent() needs to check for control disposal and such * TaskListServiceMessageControl does not check if control was already created in setMessage(). What happens if it's called twice? Apart from the technical issues I would like to discuss the following things before this goes live: * What is the process for updating the message and who decides what gets displayed? * What is a good checking interval (2 hours is way too frequently)? * Is it acceptable that this feature is opt out considering that a network connection is made automatically without user interaction? * Is sufficient to have preference for integrators to disable this feature, e.g. if Mylyn is bundled in another tools that already has a notification mechanism? As far as I understand the discussion, the purpose of this feature is to notify the user when an important update is available. Currently, messages can include a URL which is opened in a browser but do not support other interactions such as installing the update which limits is usefulness. Particularly with EPP packages where Mylyn is not installed as a root IU and a check for updates only succeeds when the actual package is updated (bug 311319).
Created attachment 169882 [details] v5 Mintor update to address the technical issues raisedL: * -Handling of the stop event in TaskListServiceMessageControl.handleEvent() needs to check for control disposal and such- * -TaskListServiceMessageControl does not check if control was already created in setMessage(). What happens if it's called twice?-
(In reply to comment #28) > Apart from the technical issues I would like to discuss the following things > before this goes live: > > * What is the process for updating the message and who decides what gets displayed? For now, we assume that committers need to vote for a message before it can be pushed. I'll write this up, since we will also need to decide on an interval (eg, max 1 message/month unless a service disruption). > * What is a good checking interval (2 hours is way too frequently)? Let's go with 1 day for the RC phase. At the next meeting lets decide on an interval that's less frequent (eg, 7 days) > * Is it acceptable that this feature is opt out considering that a network > connection is made automatically without user interaction? Yes, following the precedent of Firefox and other tools that need to inform the user of important fixes or updates, I think it is. Will write this up. > * Is sufficient to have preference for integrators to disable this feature, e.g. > if Mylyn is bundled in another tools that already has a notification mechanism? Yes, a preference seems like the right way, and better than forcing them to exclude a bundle.
Created attachment 169902 [details] v6 As committed. Service messages retrieved every 24hrs.
As discussed we want to try the following to improve the new user experience: When the task list is empty (i.e. has never been interacted with) show a message that has a link to the wizard for adding a task repository. The message control should also show a wrench icon to the left of the X that brings up the preference page for disabling messages.
An initial service message now displayed that opens the new wizard dialog. Currently this is hard coded. Looked into making this available as part of the xml from the server but would require implementing caching/paging client side. Something I don't think we have time for at this point. Added preference button top right next to close button.
Created attachment 170600 [details] initial message
I don't think it makes sense to show the initial message for users who have already used Mylyn and created repositories. Can we add a check if any user created repositories exist and not show the message in that case?
(In reply to comment #35) > I don't think it makes sense to show the initial message for users who have > already used Mylyn and created repositories. Can we add a check if any user > created repositories exist and not show the message in that case? Agreed. Fix is now in head.
Nits: * Use the the same color as the notifications popup (dark blue by default on Windows) since that's computed correctly. * The "x" for close should be in the top right, as with the notification popup.
(In reply to comment #37) > Nits: > * Use the the same color as the notifications popup (dark blue by default on > Windows) since that's computed correctly. Done. > * The "x" for close should be in the top right, as with the notification popup. Done.
Created attachment 170980 [details] screenshot 2
*** Bug 315235 has been marked as a duplicate of this bug. ***
As discussed on the call today I would like to disable remote polling of the message for now until we have figured out whether this should be opt-in and if we have sufficient infrastructure capacity for polling. We also need to revisit the update story for SR1 to ensure that if an update message is presented users can easily install it. Since 3.4 will only display a single message on startup of a clean workspace we can remove the wrench for this release. Rob, can you comment that out for now? It's likely that we will want to bring it back for SR1 though.
Created attachment 171059 [details] patch to disable service message job and preferences Patch as committed to disable job, wrench icon, and tasklist preference.
Created attachment 171060 [details] mylyn/context/zip
Thanks! Looks like we are done here then.
