id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	branch_state	votes
3247	status_msg_init's delay of 1 sec is way too large	egmont	andrew_b	"Followup of #2136:

status_msg_init() is always called with a delay of 1 second.  This delay is very bad, it's a terrible, frustrating user experience.

This means that an action initiated by the user (e.g. press Ctrl+space on a large directory to compute its recursive size, or start copying a large directory tree) often doesn't have any visible feedback for this long.  When it comes to usability and UI responsiveness, 1 second is much larger than okay.

1 second is way too large for you to start wondering whether you didn't hit the particular button hard enough, or hit the wrong key, or the wrong window is focused, or something else went wrong.  You start looking around hunting the cause, or maybe even reach out with your fingers to press Enter again, or something like this.  Actually, 1 second is large enough to press the key again which might have unexpected consequences.  Or you just sit there wondering why mc is so goddamn slow (it is not, it just makes you believe this.)

Generally, any keypress should have a much quicker, preferably immediate feedback to let the user know that mc has indeed received the keypress and is doing its job.

It is even worse when a previous dialog is about to disappear (e.g. you start copying by pressing Enter in the F5 dialog), here at least the old dialog should disappear immediately rather than with a delay.

I think that around 0.1 sec (which is 2-3 frames with the standard 24 FPS) would be okay for such a delay, it's probably soon enough that you don't begin wondering why mc didn't act on your keypress, yet avoids a flicker if the operation completes quickly.

(Note: you cannot avoid all the flickers: no matter when you present the popup dialog, it's always possible that the operation completes just after that.)

I would personally totally remove this delay.  It just causes more complicated code and worse user experience.  I'm not sure about the internals of terminal emulators in general, but I do know VTE (gnome-terminal) quite well, and this one definitely doesn't update its display immediately, it has a rate limit for its updates.  I'm pretty sure it's the same for most (all?) other terminal emulators, otherwise they'd be slow as hell.  This means that if mc draws a dialog, completes its action really quickly, and finally removes the dialog, most likely the dialog never makes it into actual X11 pixels.  Such a buffering layer under mc pretty much makes status_msg_init()'s delay pointless.

Even if you decide not to remove the asynchronous behavior and not to simplify the code, please at least significantly decrease the timeout, maybe to ~0.1 seconds or so (and please make it a #define rather than repeating this value all over the code).
"	defect	closed	major	4.8.14	mc-core	4.8.13	fixed					merged	committed-master