Community
Participate
Working Groups
It is possible to pass StatusAdapters with such property (from IProgressConstants), but it is impossible to show those errors to the user (and user may want to see them). Currently it is possible to show those errors only using another StatusAdapter as a trigger.
Created attachment 90858 [details] Idea is that good direction?
Created attachment 90859 [details] mylyn/context/zip
Created attachment 92423 [details] Another fix proposition
Created attachment 92424 [details] mylyn/context/zip
This bug contains API changes.
Created attachment 92939 [details] Patch updated to HEAD Here is the patch updated to the contents of HEAD. I think there is too much going on here for us to consider such a large change this late in the game for M6.
Tod, I talked to Szymon, and indeed this is too big change. However we wondered if manipulating only the StatusManager (preferably one new method would be acceptable)?
Sorry Krzysztof. It is too late to introduce this change in M6.
It is necessary to decouple StatusManager from Jobs in general. StatusManager should not have a lot of imports.
Szymon, I have hit quite serious obstacle in this bug - 'Progress' view. It duplicates some of SH functionality (display jobs with their statuses and suggested actions) and may cause some inconsistency especially when it comes to *deleting* finished jobs. Progress view takes input from ProgressManager and is completely independent from SH framework and it handles deferred statuses correctly. Delegating that functionality to SH would cause Progress View to stop displaying finished jobs - this is rather big change in UI and we should think twice before making any step in that direction. Another thing is that finished job returns status, so when an error occurs we could receive a couple of Job statuses and one error. It will be confusing to the user. I believe that the best option right now is to plug SH into progress, so when deferred status arrives, progress notification displays red cross.
Created attachment 116308 [details] Fix proposition (still under testing)
Need help! This bug is not going to be easy one - there is a huge compatibility gap: it is necessary to introduce new API to get rid off progress API in StatusManager. But if we remove that API it is mandatory for handlers to use new API. Old handlers do not use it - so we need to maintain old functionality => progress API stays. Am I missing something?
Removing target milestone as this bug seems to be impossible to fix - we cannot remove progress usage as we need to maintain backward compatibility.
Created attachment 122403 [details] Another approach I think this is good solution.
Created attachment 122404 [details] Patch
Created attachment 122659 [details] polished patch
I have released the latest patch. StatusManager does not depend on ProgressManager anymore. To adress support for deferred statuses separate bug will be opened.
Krzysztof, can you please verify this bug?
verified in N20090307
