|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2 sw_single displays animated color splash instaed of progress bar | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Casual J. Programmer <casualprogrammer> |
| Component: | YaST2 | Assignee: | Thomas Göttlicher <tgoettlicher> |
| Status: | RESOLVED INVALID | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | casualprogrammer |
| Version: | Alpha 1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | openSUSE 11.0 | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Screenshot of the situation
yast2logs |
||
|
Description
Casual J. Programmer
2008-01-23 09:50:47 UTC
Created attachment 191448 [details]
Screenshot of the situation
Created attachment 191449 [details]
yast2logs
(In reply to comment #0 from Casual J. Programmer) > When running yast2 sw_single it goes through a sequence of reading and > refreshing the repositories registered. > > On some of the most lengthy operations there is now an animated blue splash > instead of a progress bar. That's not a bug, that's a feature. This is the new "busy animation" for processes that take an unknown amount of time. > As the cursor already shows the busy status Bug reports show that for many users this is not explicit enough. Also, a busy cursor will always remain there until the application is finished and changes it back to the normal cursor. This new busy animation, however, shows busy state as long as it receives a periodic "keep alive" signal from the lengthy process that is being performed. If it does not receive that signal for a while, it will stop the animation so the user can see that something is obviously wrong. This is different than just a busy cursor. > this should definitely show a progress bar, so the user can estimate the > required time. If we knew how long the operations take, we would do exactly that. But we don't know that, so we can't do that. Thomas, any more comments from you? IMHO this is INVALID. Well, thanks for the explanation. I think though, displaying time used up would be more informative. For instance it should be possible to display some kind of stopwatch in the bar, this could obviously be sweetened with some eyecandy. On a second thought: You may not know how long it takes, but there might be an indication of how many percent of the task is done. I.e. number records read ( written, deleted ) of so many in total that could be passed on to the user as progress bar. (In reply to comment #5 from Casual J. Programmer) > On a second thought: > > You may not know how long it takes, but there might be an indication of how > many percent of the task is done. I.e. number records read ( written, deleted ) > of so many in total that could be passed on to the user as progress bar. > Sometimes whether time nor steps are known. Only in this case the busy indicator is used. In all other cases a progress bar is shown. (In reply to comment #5 from Casual J. Programmer) > You may not know how long it takes, but there might be an indication of how > many percent of the task is done. I.e. number records read ( written, > deleted ) of so many in total that could be passed on to the user as progress > bar. Well, sure. We do that everywhere where we know how many items we will get in total. But this is just what we don't know in those cases where we use that new busy animation. For example, while reading an XML file you'll never know how many items and subitems it has until you are finished reading it. You also get no information as to the current file position such an XML reader is, so we also can't use the total file size and the offset of the record that is currently being read. |