F8devel - UI "responsiveness" improvements

[David Timms]

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.
>>
>> Culprits:
>> - 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 ?

DaveT.