Community
Participate
Working Groups
I was cloning the orion git repo and it was taking so long I thought that it had failed without reporting an error. (Bug 344011). John suggested that I try a smaller repo, which I did from the same page. So the progress messages from the original clone and the new clone were each slamming the status area. (This actually helped me to know that the original clone was still happening, which is good). But then when the smaller clone finished and posted its link to the cloned directory, it was immediately overwritten by the status update from the git client. I knew we would need a story for reporting status on multiple tasks, but didn't think I'd run into it so soon.
Does it make any sense to consider creating the progress view with browser native controls, so it looks like a download tab/dialog? I'm not sure if this is possible, I'm just thinking out loud.
(In reply to comment #1) > Does it make any sense to consider creating the progress view with browser > native controls, so it looks like a download tab/dialog? I'm not sure if this is > possible, I'm just thinking out loud. can you write more about this idea? Different browsers implement download history differently (FF has small dedicated dialog, Chrome has a html page). Do you have any particular implementation in mind that would be cross-browser? In meanwhile I did a mockup for a separate Orion explorer page for tasks: http://zaza.github.com/mockups/progress.html you can get to it trying to do a git clone from the repositories view. It's only a proposition I'm still looking forward to some more details on Tomek's idea, maybe he'll come up with something better.
(In reply to comment #2) > In meanwhile I did a mockup for a separate Orion explorer page for tasks: > http://zaza.github.com/mockups/progress.html > you can get to it trying to do a git clone from the repositories view. > It's only a proposition I'm still looking forward to some more details on > Tomek's idea, maybe he'll come up with something better. I can see how this list would be good when one is managing tasks. I'm really curious about a compact representation that I could see while on an existing page when multiple tasks are running. (For example, I started a clone, but maybe other things are going on.) I could imagine wanting to see a hover with this list, with the statuses updating, and I could click a "Manage Tasks" link to get to the page that you show. Also...if there are multiple tasks running, what is showing in the current message area? Do we show the progress if there's just one task and otherwise have something like "multiple tasks running..."?
(In reply to comment #3) > Do we show the progress if there's > just one task and otherwise have something like "multiple tasks running..."? What about a similar message to the one used for multiple downloads: "2 tasks (5 minutes remaining)" or "2 tasks (80% complete)" if the ETA cannot be easily established?
(In reply to comment #4) > What about a similar message to the one used for multiple downloads: "2 tasks > (5 minutes remaining)" or "2 tasks (80% complete)" if the ETA cannot be easily > established? I think this a nice idea. Only that probably for most of the tasks we won't get any detailed information about progress, only running/competed, for instance git operations. we could add a dojo tooltip for details. The tooltip would contain a list of tasks and their status. There is other problem Simon pointed out at Bug 344148. When should the progress service status be displayed? Meaning on what pages? If I am have 4 Orion tabs open: navigator, git status, git log and repositories view should they all display progress status when I run a git clone task? This is probably very hard to distinguish whether this page is interested in tasks running in progress service. Today if we don't have this problem, only pages that requested for a task display its progress. Maybe we could use current progress messages placeholder only for messages (not only from the progress service) and create an icon/status message for progress service somewhere less eye-caching. Then we could display it on every page.
(In reply to comment #2) > I did a mockup for a separate Orion explorer page for tasks: > http://zaza.github.com/mockups/progress.html > you can get to it trying to do a git clone from the repositories view. Look nice, I would add couple options to the view though: * "global" Remove All Finished action, just like in the Eclipse 3.x Progress view * a name filter * a way to sort task on their start time * if possible, an action to cancel the task They are pretty obvious, so I'm sure you thought about them just didn't add them to the mockup.
(In reply to comment #1) > Does it make any sense to consider creating the progress view with browser > native controls, so it looks like a download tab/dialog? I'm not sure if this is > possible, I'm just thinking out loud. Tomek, I've been googling for a technology that could provide it. I couldn't find anything that would suit us, except maybe writing a plug-in to every browser we support. Maybe you'll get more lucky? Let me know if you'll find something.
(In reply to comment #6) > * "global" Remove All Finished action, just like in the Eclipse 3.x Progress > view > * if possible, an action to cancel the task Yes, I thought about it too, I just forgot to add them to mockups. They are added now. > * a name filter > * a way to sort task on their start time I agree with those as well. We have bugs for sorting/filtering in other places, so I think we should do it together to have a common pattern. I also think we should consider paging here.
(In reply to comment #5) > Maybe we could use current progress messages placeholder only for messages (not > only from the progress service) and create an icon/status message for progress > service somewhere less eye-caching. Then we could display it on every page. How about a small icon on the right of the current progress message? http://zaza.github.com/mockups/git-repositories.html an icon with a decoration depending on the state of tasks in the progress service. Additionally a tooltip containing all running and failed tasks (without finished, because there may be really a lot of them). You can click the icon to see this: http://zaza.github.com/mockups/git-repositories-progress-details.html
I created a branch for work in progress for progress service. It's not finished yet, but shows where it goes. The main ideas: 1. I would like to move showWhile function to progress service, it has the same signature but calling showWhile for more than ones doesn't stop tracking the previous deferred 2. Recent tasks are stored in localStorage (item: "orionTasks"). 3. When page loads and localStorage tasks weren't updated for 60 seconds it replaces them with a list of tasks running on from the server 4. Each page is responsible for tracking tasks it started by showWhile. Their status is checked as it was: every 2 seconds 5. If we have a running task in the task list that is not tracked (not updated for 5 seconds) the page updates its status every 5 seconds, unless it has been updated in meanwhile 6. The list of tasks from localStorage should be displayed in a minilist (like this: http://zaza.github.com/mockups/git-repositories-progress-details.html) - not implemented yet 7. Each page can register a listener to changes of tasks from a given topic. It will be notified every time a task providing this topic is finished - not implemented yet I migrated all "showWhile" in git operations in this commit: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?h=bug344012_progressService&id=f071fdf9b6cec67b5e298144e7263ebbc71f1397 It seems to work well even if we run two tasks at a time. I only need to create a UI to display two progress messages at a time. I appreciate a review. When it's mature enough I will move all showWhile to the progress service and cleanup some duplicated functions from status.js. In the next step it would be nice to move handling 202 to some lower layer, for instance gitClient, so that UIs won't have to think if they get a task or an immediate response.
(In reply to comment #10) > 4. Each page is responsible for tracking tasks it started by showWhile. Their > status is checked as it was: every 2 seconds can you point me to the relevant code (file/line number) in the git commit you mentioned? I'd like to understand how complicated this is for a client. I'll take a look at the git code while I'm there and comment...
(In reply to comment #11) > (In reply to comment #10) > > 4. Each page is responsible for tracking tasks it started by showWhile. Their > > status is checked as it was: every 2 seconds > > can you point me to the relevant code (file/line number) in the git commit you > mentioned? I'd like to understand how complicated this is for a client. I'll > take a look at the git code while I'm there and comment... The changes in code scheduling task are for instance in: gitCommands.js, line 342 (showWhile method has the same signature) Also creating progress service is necessary, like here: git-clone.js, lines 26-28 Implementation of the whole mechanism is made in progress.js (new file).
(In reply to comment #12) So for the client changes are pretty minimal. We need to switch from "orion.page.message" to "orion.page.progress", the rest remains the same. I was playing a bit with the task list and it looks very nice. Minor comments: - TaskClient#registreTaskChangeListener a typo in the name. I would rename it to TaskClient#registerChangeListener to be consistent with the reset method. Or even better rename these methods to add/removeChangeListeners. I'm not sure if there is any convention in Orion for names, but I got used to such names for listener's methods. - The pattern used to find a progress service. So far each registered service uses the pattern "/task/*", so it does not look like it is ready for multiple progress services. - If no objections, I would rename 'task' to 'operation'. The work 'operation' is what we use in Progress View in Eclipse Desktop so it should be clear for people. - TaskClient API. I think we could simplify it a bit. I'm more a fan of methods that accepts parameters than multiple remove or get methods. So for instance we could have one #remove/delete method which accepts URIs and parameters instead of two removeCompletedTasks and removeTask methods.
(In reply to comment #13) > - The pattern used to find a progress service. So far each registered service > uses the pattern "/task/*", so it does not look like it is ready for multiple > progress services. This is caused by using relative paths only. FileClient has the same problem, I failed a bug for it: Bug 366700. > - TaskClient API. I think we could simplify it a bit. I'm more a fan of methods > that accepts parameters than multiple remove or get methods. So for instance we > could have one #remove/delete method which accepts URIs and parameters instead > of two removeCompletedTasks and removeTask methods. I'm file with getTasks and getRunningTasks, but removeCompletedTasks and removeTask do different jobs, if we would want to replace removeCompletedTasks by using removeTask that we would have to first get the list of all tasks and iterate over them doing removeTask for each of them that is not running - many calls instead of just one. I think this is a high price to pay to reducing number of methods.
I simplified taskPlugin and taskClient API: removed some gets and replaced it with a function with options, instead of register listener in taskClient I added add/removeListener. As for "tasks" and "operations" I think the good idea would be to use "operation" as every long-running operation tracked in our progress service and "task" as the implementation we currently have: tasks run on the server. I want to be sure we want to make this change because this would probably requires some renames in client that always make some cache-related problems: taskClient -> operationsClient taskPlugin -> operationsPlugin get/deleteTask() -> get/deleteOperation() task/list.html -> operation/list.html etc.
I pushed a mini task list display with an icon. You can see it on git pages now, but at the end it should be on every page. Tasks are removed from it after 5 minutes, but it still get cluttered because of all git-logs. Maybe when we create topics implementation we can remove tasks that don't have topics soon after they are consumed. This is work in progress but the main idea is there, so I'm open to suggestions. I was thinking that maybe when there are not tasks running I could resign from the popup and make the icon a direct link to task list. But it's confusing that in one situation clicking on the icon does something harmless (open a popup) and in other situation something pretty meaningful (redirecting to another page), so I left it this way. In the next step I'd like to remove messages from status and replace them with popping up this tooltip on status change. I suppose I should find a place for detailed messages there as well, not only the task name. Do we change "task" to "operation"?
Merged! I've send a mail about it on orion-dev, so here just in case: to avoid problems with changes please clear you browser cache and reload taskPlugin.html.
I can see that everyone started opening bugs as feedback, so there is no need to keep this bug as open. Just enter a bug when you want something to be changed.
