[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: F8devel - UI "responsiveness" improvements

Adam Jackson wrote:
On Thu, 2007-06-14 at 06:58 +1000, David Timms wrote:
I'd like to suggest a goal for future Fedora of ensuring every application / task performed with Fedora actually provides user feedback at a minimum 1 {one} second interval.

- anaconda between go-ahead with install and first package installing {especially noticeable because the {boring} X screen saver kicks in. You then move the mouse to get the screen back - but there is no update to the screen for maybe one minute or more.

- pup during an update run with about 30-40 packages. It took nearly an hour. Each time an app covered its windows they may not have been redrawn for some minutes.

Just to clarify, it's not that you want continuous screen updates, it's
that you don't want to see apps in the middle of redraw.
Just to clarify your clarification: I meant that eg you cover the window|switch desktop|alt-tab, and then when you go back to view progress of the app, the window decorations are drawn but the bits that have been covered (or unminimized} show as grey, and might stay this way for some time.

Or during anaconda, this occurs in the transition between one step and one where it reads the package list in. There is an initial draw, but then no change for 30secs.

Eg: during boot, my dhcp server is not responding. In the text mode, we could add a "." each second that there was no response. {actually that conflicts with the next para :( }. Or/And text stating no dhcp server has responded within a "normal" time frame. Then the fact that the dhcp request has been sent again is more progress.

The other side is that I feel that the app should show some effective "I am still working normally but the thing I'm doing is going to take some time". If it was a 10MB download and the app received bytes - then it is making progress. I would be strongly against making fake progress - eg a ms progress dialog that moves along saying it's making progress, when in fact you have pulled the internet connection on it. Or worse still - progress bars that get to the end and then clear and start again based only on time counting. {-1 also to progress dialogs that move from right to left}.

Adding an estimate of amount of time until completion would be the icing; this should take into account the "work" to be done, and the amount of work toward that end that has actually been completed. And I realize this is probably the opposite to what "usability studies" might tell ms or us. If I remember rightly, anaconda used to have estimated time to completion of install, but I think this has disappeared in recent releases.

With the push to save power at the cpu level, any timer's should really be aligned with another ticking timer {like after the seconds on the clock}.

We could solve this trivially by turning on automatic compositing by
default but I don't think that's ready yet.
Would the "automatic compositing" mean that an apps visuals are stored by the ~window system~ so that they can be redrawn by the window manager, without waiting for the app 2 update itself ?

Are these sort of issues worth working on as a common goal ? Or do I bugzilla them as enhancements / fixes in the respective apps ?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]