| Summary: | Mark Read/Unread should run outside of the UI thread | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Eddie Galvez <egalvez> | ||||||
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> | ||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||||
| Severity: | minor | ||||||||
| Priority: | P4 | CC: | robert.elves | ||||||
| Version: | 2.2 | ||||||||
| Target Milestone: | 3.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Eddie Galvez
Btw, I would not mind the priority lowering because, to be honest, this is mostly a concern when setting up queries for the first time (like a query grabbing all issues assigned to me, but that I want marked read). If you guys think it worthwhile, perhaps I'll file an enhancement to make new queries automatically mark everything that it adds as Read during the first query synchronization. (In reply to comment #1) > If you guys think it worthwhile, perhaps I'll file an enhancement to make new > queries automatically mark everything that it adds as Read during the first > query synchronization. I like that idea. It could be a check box in the new wizard for creating new queries. *** This bug has been marked as a duplicate of bug 208924 *** Oops, wrong bug. *** This bug has been marked as a duplicate of bug 205358 *** Steffen, that is a wrong bug again Just to clarify. Running actions in background job and performance/io issues seem way to different. This bug got quite some activity ... again, my bug report is strictly only to say that I think the mark read/unread action should do what it can not to run directly in the UI thread to ensure responsiveness. I'll open a seperate enhancement request for making the new-query wizard "mark imported tasks as read". The reason that marking tasks is slow is due to the I/O caused by the operation. This is particularly noticeable when marking many tasks read. The solution may require moving the I/O operations to a job and providing progress indication or a redesign of the data model to avoid doing I/O and making the operation fast. I would like to address either solution on bug 205358. *** This bug has been marked as a duplicate of bug 205358 *** Created attachment 89924 [details]
converted mark read/unread to job
Steffen, whil in a long run your ideas are good, the fix to address UI responsiveness is much simpler (see attachment) and it provides immediate benefits without significant api refactorings.
Created attachment 89925 [details]
mylyn/context/zip
Yes, that patch could work. If you want this to go into the 2.3 release I would recommend that you add it to the next meeting agenda and ask Rob to review it. I am not sure what the implications of running the actions on a non-UI thread are. Rob, can you please take a look at this? The patch did not make it into 2.3. Further improvements will be tracked on bug 205358. *** This bug has been marked as a duplicate of bug 205358 *** |